Extension talk:OpenID

Jump to: navigation, search

About this discussion

Archives 

Archive 1 - Archive 2

It is preferred that you open a regular bug report for new issues.
Warning: Please do not use the google discussion group to discuss this extension. I as maintainer do not follow the discussions there. You are kindly asked to discuss the extension here, watch this page, have your e-mail notification enabled, and your e-mail address confirmed. --Wikinaut 00:35, 14 February 2012 (UTC)

First aid checklist

checklist 1: Did the OpenID extension ever work before ?
status quo ante your answer (my hints in italics)
Did the OpenID extension ever work before?
What constellation (version numbers of MediaWiki, OpenID, PHP see Special:Version on your wiki) has been known to work before?
Are you trying to use the extension from an intranet? If you can, check the proxy and fire wall settings. Contact your intranet system administrator and ask if and what exactly they have changed recently.
What has been changed on your system, and when?
Did you re-install, upgrade or move your MediaWiki installation recently? We do know of problems of remains from different versions when mixing or upgrading from an unknown status. If you can, then delete your complete installation and the extension and try a fresh installation.
When you installed OpenID extension manually after your MediaWiki, you need to run php update.php once before it can be used. Have you done it really? If you are unsure, and want to be on the safe side, then run it now again.
When did you notice the problem for the first time?

Before posting a question and request for help here, please check the presence of prerequisites with a small file in one of your web accessible directories.

<?php
phpinfo();
?>
Warning: Do not reveal the output to the public. Do not post its output here or somewhere else, unless this is a safe place. After use, it is a good practice to wipe the script file from your web server in order not to give details of your system configuration to evil persons.

Access the phpinfo script with your web browser. Scrutinize the output very carefully, whether the following libraries are really installed, maybe as php module or as installed library. Look carefully through the whole output, what you are looking for might be at the end. If one of the modules is missing, please install the missing module, or recompile PHP to include the required modules to libphp5.so). This is explained on the main page of the extension.

checklist 2: PHP modules, which the extension requires
check the output of phpinfo():

library

is support installed for this?
openssl
gmp
mcrypt
bzip2

Along with your question, please indicate versions from your wiki's version page

checklist 3: MediaWiki components
check your wiki's version page

for component

what version do you run?
MediaWiki version and revision
PHP
OpenID extension version and revision

Please study the MediaWiki debug manual. Before reporting here, please always check your logfiles for obvious problems such as missing files due to wrong include paths and so. Add the following line temporarily to your LocalSettings.php and try to log in with OpenID

$wgDebugLogFile = "/tmp/{$wgSitename}-debug.log"; // my wiki's debug logfile - comment the line after use
Warning: Make sure to have the debug file unaccessible for the public, and via the web, as the debug file may contain confidential information such as cookies.
checklist 4: Webbrowser, System, and MediaWiki debug logfiles
check your logfile are there fatal errors or warnings logged with relevance to OpenID extension, or MediaWiki?
/var/log/apache2/error_log
/var/log/messages
/tmp/<yourWikiSitename>-debug.log look for lines starting with OpenID:

After finishing the checklist tests, don't forget to

  • remove the phpinfo script
  • disable the debug logging
  • remove the debug log file



It is preferred that you open a regular bug report for new issues.


By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

OpenID 2.0 for Google Accounts has gone away

2
Golom4433 (talkcontribs)

My extension installation stopped working.

The versions I currently use:

MediaWiki 1.19.1

OpenID extension 1.004 20120427

Can someone tell me what I have to do to make it work again? Change the configuration of the extension or also install the latest version?

Thank you

John Broughton (talkcontribs)

Google doesn't support Open ID 2.0 anymore. It has been replaced by OpenID Connect, as stated here: https://developers.google.com/identity/protocols/OpenID2Migration

Reply to "OpenID 2.0 for Google Accounts has gone away"

How to use/store given URL instead of delegate URL

2
Psmay (talkcontribs)

TL;DR: Since the last time I upgraded, the extension has changed from using, checking, and storing the given URL to doing so with the delegate URL when delegation is in use. This doesn't work well for our system.

Just upgraded to 4.03 from…0.9.0 (!) and have found a change that I need to either disable or revert to get our wiki back up and running.

There is a site that I run, one with a short URL (http://psmay.com/), and I'm using OpenID's delegation facility to delegate to Launchpad as the provider that authenticates for that page (i.e. <link rel="..." href="https://login.launchpad.net/..." /> elements are provided for openid.server, openid.delegate, openid2.provider, and openid2.local_id).

Apparent previous (and as far as I am concerned, correct) behavior:

  • When I sign in with http://psmay.com/, the string http://psmay.com/ is compared against the allow/deny lists, delegation and authentication takes place, and then I am confirmed as having signed in as http://psmay.com/. My user's account has been associated with this URL.
  • When I sign in with psmay.com, that is converted to http://psmay.com/, and the process continues as above. (I am not sure whether allow/deny is applied before or after the conversion.)

Current behavior:

  • When I sign in with http://psmay.com/, the string http://psmay.com/ is compared against the allow/deny lists, delegation and authentication takes place, the ultimate delegate URL is compared against allow/deny, and I am confirmed as having signed in as the delegate URL. That URL not being in the database, the extension offers to associate me with another user.
  • When I sign in with psmay.com, the string psmay.com is compared against allow/deny, then converted to http://psmay.com/, and the process continues as above.

While I realize that the change might actually have been intentional, there are issues with the new behavior:

  • Both the user URL (http://psmay.com/) and the delegate provider URL (https://login.launchpad.net/...) must be accounted for in the allow/deny patterns. For our purposes, only the user URL should be important.
  • The URL representing the user has been changed from the user URL to the delegate URL.
    • Any user account already associated with a URL that delegates is now broken.
    • If I fix up the database so an account is now connected to the delegate URL, the user can't later decide to change to another delegate URL without losing access.

Any way to fix or work around this? Am I the first to ask?

Wikinaut (talkcontribs)

I need to understand your report, allow me some time. The present moment (Heartbleed fixes and other things) is not so well suited.

Just one remark: the old OpenID extension versions did never correctly handle the delegation, only the new versions do. So we both should concentrate to find, why the new version is (perhaps) not working within your environment. I suggest you remove(open, drop) the allow/deny restrictions, and check the exact url. In almost all cases I do remember, there was a difference between the Url you see and the Url which the remote server sees with MediaWiki (I mean the difference between server/wiki/Special:Pagename and server/w/index.php/Special:Pagename for example.).

And I also suggest - if you can - to run the latest core Mediawiki and latest OpenID extension on latest PHP 5.5.11.

You are also invited to file a bugzilla https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=OpenID for this (copy the texts from here, and leave a link the bugzilla). Bugzilla is better trackable, and allows attachments, links to gerrit etc.

Reply to "How to use/store given URL instead of delegate URL"

OpenID extension doesn't work at all?

7
130.183.2.70 (talkcontribs)

Hello,

I installed the OpenID extension and everything seems to work fine. But when I choose a provider to login, all the pre-configured providers are failing. For example, Google says:

Fehler:invalid_request Error in parsing the OpenID auth request.

Also Yahoo! doesn't works:

Sorry! There is an error with the request we received from the website you are trying to use. Please try again in a few minutes. If this error persists please contact the site administrator.

At least, I want to allow login only for users comming from our own Drupal installation (which acts as an OpenID provider). Also this doesn't works, when I choose "OpenID" and enter my own URL, I got the error:

Verification error An unspecified authentication response/request error occurred during the verification of the OpenID URL https://rd-alliance.org/user/1341/identity.

I actgivated the logs and get the output:

Start request POST /dft/index.php/Special:OpenIDLogin
HTTP HEADERS:
HOST: smw-rda.esc.rzg.mpg.de
USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
ACCEPT-LANGUAGE: de,en-US;q=0.7,en;q=0.3
ACCEPT-ENCODING: gzip, deflate
REFERER: http://XXXX/dft/index.php?title=Special:OpenIDLogin&returnto=Main_Page
COOKIE: dftwiki_openid_provider=Google; dftwiki_openid_provider_param_OpenID=https%3A%2F%2Frd-alliance.org%2Fuser%2F1341%2Fidentity; dftwiki_openid_provider_param_AOL=; dftwiki_openid_provider=OpenID; dftwiki_openid_provider_param_OpenID=https%3A%2F%2Frd-alliance.org%2Fuser%2F1341%2Fidentity; mediawikiUserName=Tom; mediawikiUserID=1; vector-nav-p-tb=true; vector-nav-p-Help=true; dftwikiUserName=Tom; dftwikiLoggedOut=1397119404; dftwiki_session=o8h4jasm6smrb0m2td0iq07iup74n7uhvnshhbbgqkbs2c68nk50
CONNECTION: keep-alive
CONTENT-TYPE: application/x-www-form-urlencoded
CONTENT-LENGTH: 132
CACHES: EmptyBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser]
[cookie] session_set_cookie_params: "0", "/", "", "", "1"
LocalisationCache: using store LCStore_DB
Fully initialised
IP: 130.183.2.70
Connected to database 0 at localhost
Connected to database 0 at localhost
MessageCache::load: Loading en... got from global cache
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser
Parser: using preprocessor: Preprocessor_DOM
Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct
OpenID: Attempting login with url: https://XXXX/user/1341/identity
OpenID: no auth_request for https://XXXX/user/1341/identity
Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from OpenIDHooks::onPersonalUrls in /srv/www/htdocs/dft/extensions/OpenID/OpenID.hooks.php at line 90]
OutputPage::sendCacheControl: no caching **
wfShellExec: /bin/bash '/srv/www/htdocs/dft/includes/limit.sh' ''\''/usr/bin/php'\'' '\''/srv/www/htdocs/dft/maintenance/runJobs.php'\'' '\''--maxjobs'\'' '\''1'\'' &' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=180; MW_CGROUP='\'''\''; MW_MEM_LIMIT=307200; MW_FILE_SIZE_LIMIT=102400; MW_WALL_CLOCK_LIMIT=180'

This is the configuration I have in LocalSettings so far:

require_once ("$IP/extensions/OpenID/OpenID.php");
$wgTrustRoot = "http://XXXX/dft/";
$wgOpenIDOnly = true;
$wgOpenIDMode = array( 'consumer');
$wgDebugLogFile = "/tmp/wiki.log";

Any idea whats going wrong?

Wikinaut (talkcontribs)

Please indicate the versions! MediaWiki, OpenID, PHP. It is suggested you update everything to the lastest releases.

130.183.2.70 (talkcontribs)

The Mediawiki + OpenID is installed on a Suse Linux Enterprise 11 SP 3 system:

- Mediawiki: 1.22.1 - OpenID: 3.42 - PHP: 5.3.17 - php-openids's Auth folder is in place - gmp, mcrypt, openssl, xml, curl is in place

Please tell me if I should provide more debug info?

Wikinaut (talkcontribs)
  • login to your server (command line)
  • try with "wget www.google.de/....." or with cur

whether your server is able to access the OpenID provider. This is essential.

Perhaps you are using SLES in an intranet and you have to define a proxy.

Try "wget http://www.google.com". Does this work? You need to get it working.

130.183.2.70 (talkcontribs)

Yes of course, the server is on the internet and can reach everything.

Wikinaut (talkcontribs)

Please check that the Url(s) (OpenID server) you are accessing are not https Url(s), which your server *perhaps* cannot fetch, try it on the command line to make 100% sure that you do not have a proxy or certificate problem.

Ah, and update the OpenID extension (use the version from git) which is now at version 4.03. I cannot give support for older versions, sorry.

Jskang (talkcontribs)

I had same problem. And my server could not access the OpenID provider 'www.google.com'. The Datacenter(in south korea) where my server is located in was on check for oversea network. Now everything works fine. Thanks for the advice!!

Reply to "OpenID extension doesn't work at all?"

[SOLVED] https site and Special:Badtitle

4
Summary by Wikinaut

see Bug 54512 E:OpenID needs to work with $wgSecureLogin

Atao60 (talkcontribs)

- MediaWiki: 1.22.3
- OpenId: 4.03 20131126
- PHP: 5.3.28 (cgi-fcgi)
- MySQL: 5.1.73-1
- Apache: 2.2.16
- Debian: 7 (wheezy)
- php supports
-- openssl: OpenSSL 0.9.8o
-- gmp: no
-- mcrypt: 2.5.8
-- bzip2: no (only zip & zlib)

As long as the site is reached through http url, everything runs fine.

When I force https for the full site with .htaccess:

RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L]

when I try to connect, the verification fails and I get:

‘ Mauvais titre Aller à : Navigation, rechercher Le titre de la page demandée est invalide, vide, ou il s’agit d’un titre inter-langue ou inter-projet mal formé. Il contient peut-être un ou plusieurs caractères qui ne peuvent pas être utilisés dans les titres. Revenir à la page Accueil. ’

that is: "Bad title" The requested page title was invalid, empty, or or include a non-local or incorrectly linked interwiki prefix. It contains a link to return to the welcome page.

Is there any specific parameter to be configured when the full site can be reached only through https?

Atao60 (talkcontribs)

After some more digging, I figured out that it's related to the http/https agnostic value of $wgServer, e.g.: "//mysitename.net". So I added in LocalSettings:

if ( isset($wgServer) && (substr( $wgServer, 0, strlen('http') ) !== 'http') ) {
    $wgCanonicalServer = 'https:' .  $wgServer;
}    

But now I get an issue quite same as in Return to Special:Badtitle instead of the main page after verification has succeeded.

After logging in with OpenID (using Google Apps), on the "Vérification réussie" ("Verification Succeeded") page the last line always reads "Revenir à la page Spécial:OpenIDLogin." ("Return to Spécial:OpenIDLogin."). If I click on this last link, I get a view "Page spéciale inexistante" ("Unknow special page") with a "Return to" link to the Welcome page.

The issue is now to avoid the display of the "Unknow special page", ie a link to the welcome page from the Verification Succeeded page.

Any idea?

Wikinaut (talkcontribs)

Hello, thanks for your report. Can you please check, whether https://bugzilla.wikimedia.org/show_bug.cgi?id=54512#c5 is related to your problem?

Atao60 (talkcontribs)

Hello, thanks for your answer.

I'm unable to say if my issue is related to the bug 54512. But https://bugzilla.wikimedia.org/show_bug.cgi?id=54512#c1 helped me to realize I have been ignoring $wgSecureLogin parameter. As soon as I add $wgSecureLogin=true, evething runs fine! So I'll let you draw any relevant conclusion...

Again, thank you.

Reply to "[SOLVED] https site and Special:Badtitle"

Return to Special:Badtitle instead of the main page after verification has succeeded

2
Go2dev (talkcontribs)

I'm using OpenID (Version 3.42 20131004) in conjunction with MW 1.22.2 for a private wiki and am experiencing an error with the return link on the login success page. The server is running:

PHP 5.4.26 (cgi-fcgi) MySQL 5.5.36-cll Apache 2.2.26 (Unix)

After logging in with OpenID (our organisation is using Google Apps) on the Verification Succeeded page the last line always reads 'Return to Special:Badtitle.' instead of "Return to Dashboard" (Dashboard being the main page for our wiki). 'Return to Dashboard' appears on the Bad title page if you click through the link.

The 'Return to Special:Badtitle.' link also appears if a user returns to the login success page where the title reads 'You are already logged in'.

I know this issue has cropped up before but all the posts I've seen are related to older versions of the extension and MW.

According to the log, the Special:Badtitle is part of the referrer during the OpenID login process - here's a section from the log file:

:Start request POST /w/index.php?title=Special:OpenIDLogin
:HTTP HEADERS:
:CONTENT-LENGTH: 127
:CONTENT-TYPE: application/x-www-form-urlencoded
:ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
:ACCEPT-ENCODING: gzip,deflate,sdch
:ACCEPT-LANGUAGE: en-GB,en;q=0.8
:CACHE-CONTROL: max-age=0
:CONNECTION: keep-alive
:COOKIE: random_hb_openid_provider=Google; wikiEditor-0-booklet-characters-page=latin; wikiEditor-0-booklet-help-page=discussion; vector-nav-p-recentchanges-url.7Crecentchanges=true; vector-nav-p-Wiki-Ops=true; vector-nav-p-categorytree-portlet=false; __utma=175913889.1062613182.1380626510.1394545934.1394807252.38; __utmz=175913889.1393577105.31.3.utmcsr=web.hostingprovider.net:port|utmccn=(referral)|utmcmd=referral|utmcct=/cpsess8511562650/scripts4/listaccts; random_hb_session=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; random_hbLoggedOut=xxxxxxxxxx; random_hbUserID=2; random_hbUserName=username; random_hbOpenID=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; vector-nav-p-Media_Wiki=true; vector-nav-p-tb=true
:HOST: hb.random-international.com
:ORIGIN: http://subdomain.ourdomain.com
:REFERER: http://subdomain.ourdomain.com/w/index.php?title=Special:OpenIDLogin&returnto=Special:Badtitle
:USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.154 Safari/537.36
:CACHES: EmptyBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser]
:[cookie] session_set_cookie_params: "0", "/", "", "", "1"
:Class LanguageEn_gb not found; skipped loading
:LocalisationCache: using store LCStore_DB
:Connected to database 0 at localhost
:Unstubbing $wgParser on call of $wgParser::setHook from wf_include
:Parser: using preprocessor: Preprocessor_DOM
:Fully initialised
:IP: xxx.xxx.xxx.xxx
:Connected to database 0 at localhost
:MessageCache::load: Loading en-gb... got from global cache
:Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct
:MessageCache::load: Loading en... got from global cache
:OpenID: Attempting login with url: https://www.google.com/accounts/o8/id
:Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from OpenIDHooks::onPersonalUrls in /home/random/public_html/hb/w/extensions/OpenID/OpenID.hooks.php at line 90]
:Parser: using preprocessor: Preprocessor_DOM
:OutputPage::sendCacheControl: private caching;  **
:wfShellExec: /bin/bash '/home/username/public_html/subdomain/w/includes/limit.sh' \/usr/bin/php'\ '\/home/username/public_html/subdomain/w/maintenance/runJobs.php'\ '\--maxjobs'\ '\1'\ &' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=180; MW_CGROUP='\\; MW_MEM_LIMIT=307200; MW_FILE_SIZE_LIMIT=102400; MW_WALL_CLOCK_LIMIT=180'
:Request ended normally
:wfClientAcceptsGzip: client accepts gzip.
:wfGzipHandler() is compressing output
:

There's nothing of note in /messages and /apache2/error_log.

Any ideas where I should starting looking to debug this?

On a related point, it would be useful if the login page automatically redirected to the Dashboard/main/home page after a few seconds instead of sitting there. Can this safely be added as JS in the PHP file which defines what appears on that page or is that a bad idea? Is it an option that I missed?

Comments and suggestions most appreciated Best D

Atao60 (talkcontribs)

This is a sequel of https site and Special:Badtitle

I thought my issue was solved. But things are never so simple. Now my Mediawiki site behaves exactly as described by the first post on this thread:

  • verification succeeds
  • on the Verification Succeeded view the last line displays a link to 'Return to Special:Badtitle.'

I'm unable to figure out what I have done that changed the Mediawiki behavior. The only thing I think about is I purged all the caches of Firefox. I don't know if it can be related.

[EDIT] 29/03/2014. And today the issue has vanished... I've no clue about this erratic behavior...

Reply to "Return to Special:Badtitle instead of the main page after verification has succeeded"

[SOLVED] $wgOpenIDTrustRoot

1
Summary by Wikinaut

filed as bug 57478: "make $wgOpenIDTrustRoot protocol-independent"

Kghbln (talkcontribs)

In case a website is available via http as well as https: What should the trusted root be set to (http://www.example.com/ or https://www.example.com/)? I guess it should be the latter (https). Cheers

Reply to "[SOLVED] $wgOpenIDTrustRoot"
Myrtonos (talkcontribs)

If OpenID and Title blacklist are both installed together, does title blacklist still block creating of OpenID accounts with blacklisted usernames.

Wikinaut (talkcontribs)

Hi, I haven't that tested yet but think the answer will unfortunately be "no". See also Bug 54677: Do account creation checks when creating users.

Reply to "OpenID with Titleblacklist"

Pitfall of this extension

3
Summary by Wikinaut

already known and filed as Bug 34357. I admit, that quickly a solution or workaround has to be found. The bug documents, why this problem appeared suddenly (because MediaWiki has changed and now demands a password for e-mail address change.)

But please upgrade your OpenID extension. The present version is much better and has an improved Preferences tab where you can manage your OpenIDs.

Rob Kam (talkcontribs)

I've created a login on a wiki via OpenID (using MyOpenID). Now when I go to Special:ChangeEmail it doesn't accept any password and if I go to Special:PasswordReset it can't because no email is set. I've tried ticking all in preferences for updating from OpenID every time I log in but that hasn't helped. MediaWiki 1.19.2 and OpenID 1.004 20120427.

Rob Kam (talkcontribs)

I managed to work around the problem at Special:Preferences#mw-prefsection-openid, by associating a StackExchange OpenID and setting the option to update the password at login. I couldn't get the same to work with MyOpenID.

It's not my wiki, so I'm unable to upgrade the OpenID extension.

Wikinaut (talkcontribs)

Thanks for reporting. The way you decribed is also what I would recommend, but is may not be always possible to add further OpenID.

Reply to "Pitfall of this extension"

[SOLVED] How to login with OpenID in private wiki?

4
Jskang (talkcontribs)

I have a private wiki. I chose 'private' type when I set up wiki.

So, codes like below was automatically inserted in 'LocalSettings.php' file.

# Disable reading by anonymous users
$wgGroupPermissions['*']['read'] = false;

And after install OpenID extension, I clicked "Log in / create account with OpenID" link,

but it says "You must login to view other pages."

This means, "read permission is required to view the 'OpenID Login page', but anonymous user doesn't have read permission"

How can I solve this dilemma?

Jskang (talkcontribs)

I whitelisted the page 'Special:OpenIDLogin' in LocalSettings.php like this :

$wgWhitelistRead = array("Special:OpenIDLogin");

The page name(title) depends on default wiki language($wgLanguageCode in LocalSettings.php).

Wikinaut (talkcontribs)

If I understand correctly, you solved your problem. Is this correct ?

Jskang (talkcontribs)

Oh.. I forgot to say that's solved. Yes, now anyone can access the page "Log in / create account with OpenID" even if the wiki is private.

Reply to "[SOLVED] How to login with OpenID in private wiki?"

OpenID with [[Extension:ConfirmAccount|ConfirmAccount]]

7
Myrtone (talkcontribs)

What would happen if someone installed OpenID and confirm account on the same wiki?

Wikinaut (talkcontribs)

Good point, this is not clear, but you can simply try it and let us know (here).

By the way, we are working on a small improvement of Extension OpenID Bug 46617 which allows admins to create new accounts by mail for wikis where the login is disallowed for anons.

Myrtone (talkcontribs)

Another related bug is that, even if an account is created using an OpenID and without a password, it is not possible to specify a valid email address, because that action itself requires the vaild password to be specified.

Wikinaut (talkcontribs)

This problem is filed as Bug 34357.

Gleki.arxokuna (talkcontribs)

Hello, ConfirmAccount and OpenId work together on my wiki but !

If someone wants to login with OpenId they have only one option: to provide their login and password on the wiki. One has only one option:

"An existing account on this wiki"

When entering a new login and password it just says "Incorrect password entered. Please try again." So there is not option to create a new account although the button is "Log in/create account"

Wikinaut (talkcontribs)

Hi, thanks for reporting.

What is offered depends also on your OpenID settings, see the Manual page of OpenID. And please indicate your exact version. If you run a modern MediaWiki, then I strongly suggest you run the latest OpenID version from Github.

Let me know, if I could help.

Gleki.arxokuna (talkcontribs)

I'm running MW 1.24 alpha, using the latest master versions of ConfirmAccount and OpenID. Still when ConfirmAccount is enabled I can't create a new account since this option is disabled. I can only link to an existing account whe using a Google account. When using a Yahoo account it just returns "Verification failed" page.

"$wgOpenIDAllowNewAccountname=true" wouldn't work since I can't set "$wgGroupPermissions['*']['createaccount'] = true;" since it would defeat the whole purpose of ConfirmAccount extension.

Any other clues?

Reply to "OpenID with [[Extension:ConfirmAccount|ConfirmAccount]]"