Extension talk:OpenID

Jump to: navigation, search

About this board

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

Suggestion: change $wgOpenIDConsumerForce so that it fully specifies an OpenID provider (Url, logo, ...)

4
UnwashedMeme~mediawikiwiki (talkcontribs)

I have a patch (committed in my git repo) that I would like reviewed for inclusion. I clicked around and searched somewhat but didn't see any documentation here about submitting patches.

I've registered at gerrit.wikimedia.org; and I see that it gives me a git remote url customized to my user. Should I just push to there and that will launch a new review entry?

Cheers, Nathan Bird

This post was posted by UnwashedMeme~mediawikiwiki, but signed as UnwashedMeme.

Wikinaut (talkcontribs)
  • hi, what is that patch about ?
  • Is it based on my latest version Version 1.004 20120427 ?
  • have you tested locally everything so that you are fully sure your patch does not break anything ?
UnwashedMeme~mediawikiwiki (talkcontribs)

I'd left the question deliberately vague trying to create a generic "How do you submit patches" documentation bit.

I actually have a series of patches in git, pulled from gerrit as specified in the download section. The patches are currently based on 7e5b4d13b9 (master as of writing this).

This is about extending $wgOpenIDConsumerForce to be able to specify an OpenIDProvider instead of just a flat URL. This is useful if the provider varies by username and you wish to display the login form like the builtin providers.

  • If you specify $wgOpenIDConsumerForce as a string it continues to behave as before (tested).
  • If you don't specify $wgOpenIDConsumerForce it continues to behave as before (tested).
  • If you specify an OpenIDProvider, e.g. $wgOpenIDConsumerForce = new OpenIDProvider('wp', 'www.wordpress-site.com', 'Wordpress-site.com Username', 'http://www.wordpress-site.com/author/{username}/' ); it will display a login form asking for the username; skips rendering other providers' forms. (tested and using)

In the last case (or a future one with a specified list of providers, instead of just the one) the generic provider 'openid' (arbitrary url) may not be present. To handle this I removed the special case logic in

  • OpenIDProvider::getLoginFormHTML
  • skin/openid.js

The special case used to, for the provider 'openid', name the field 'openid_url' instead of "openid_provider_param_$id". There is now a hidden input 'openid_url' always present and the 'openid' provider is treated the same as everything else.


I tried to test the code paths that were effected by the change I made after each patch. There are quite a few options though so there is a chance that I missed one that would be a confounding factor. To ease review I tried to break it into several logically distinct patches that stepped in the right direction.

This post was posted by UnwashedMeme~mediawikiwiki, but signed as UnwashedMeme.

UnwashedMeme~mediawikiwiki (talkcontribs)

Searching for information on Gerrit I came across: http://www.mediawiki.org/wiki/Git/Tutorial#How_to_submit_a_patch; would this be a good procedure for this extension, which appears to be housed in the same domain?

Gerrit appears to prefer commits to not be a series; it looks like it creates separate reviews for each commit in a branch when you push. I've squashed some of the commits but I think it will be more palatable as several reviews unless you would specifically like to avoid that.

This post was posted by UnwashedMeme~mediawikiwiki, but signed as UnwashedMeme.

Reply to "Suggestion: change $wgOpenIDConsumerForce so that it fully specifies an OpenID provider (Url, logo, ...)"

OpenID with Google Apps

8
Summary by Wikinaut

I think, what you all want is what we call "forced provider". See https://gerrit.wikimedia.org/r/#/c/55287/

You can already try it:

git fetch https://wikinaut@gerrit.wikimedia.org/r/mediawiki/extensions/OpenID refs/changes/87/55287/54
git checkout FETCH_HEAD

This should tell you "OpenID version 3.40" in Special:Version . See README and OpenID.php for documentation, the manual page will be updated when this code is actually merged.

--Wikinaut (talk) 10:57, 8 August 2013 (UTC)

Okthen~mediawikiwiki (talkcontribs)

We are hoping to set up a private cloud wiki and would like to make sure that it is locked down to users within our organization. We have a domain with Google Apps and this would be ideal to use for authenticating our users into the wiki. I am using a fresh install without any content though it is a canned bitnami hosted installation rather than rolling my own from the ground up.

I have been able to configure the OpenID extension and I can log in with my own Google credentials. I am not clear on whether I have locked it down to just our own organization or from Google if it would still authenticate any OpenID from any provider. I would like the user names to be the user part before the @ of the email address.


I have tried to search for specific instructions on configuring the OpenID extension to only use Google Apps but without success, if anybody can point me to a step by step guide I will attempt that before taking up anyone's time on here. To re-iterate, I want to only allow access to people in my domain authenticating with Google. (In future I may wish to grant access to users outside our Google App domain but have them sign up with a regular login and then manually grant them access.)

Meanwhile here are some details about our installation pasted from the Version page



 MediaWiki 1.19.1
 PHP 5.3.13 (apache2handler)
 MySQL 5.5.21-log
 OpenID(Version 1.004 20120427)
 


My LocalSettings.php looks like this (Updated since first posted, I have re-read the README and figured out how to only use Google as the provider)


 #// *** OpenID Configuration ***
require_once( "$IP/extensions/OpenID/OpenID.php" );
$wgTrustRoot = "http://okthen.bitnamiapp.com/mediawiki/";
#$wgOpenIDOnly = true;
#$wgOpenIDConsumerDenyByDefault = true;
$wgOpenIDConsumerForce = "https://www.google.com/accounts/o8/id";
$wgOpenIDUseEmailAsNickname = true;
$wgOpenIDAllowExistingAccountSelection = false;
$wgOpenIDAllowNewAccountname = false;
$wgOpenIDShowProviderIcons = true;
$wgOpenIDLoginLogoUrl = "http://www.google.com/favicon.ico";

I am not clear on how I can only allow folks who are part of my domain hosted on google apps to login.

I have not modified anything in the OpenID extension folder.

This post was posted by Okthen~mediawikiwiki, but signed as Okthen.

198.177.94.250 (talkcontribs)

Did you ever get this figured out? I am trying to do the same thing but keeping getting stuck!

49.176.37.84 (talkcontribs)

Seconded. I need this also.

Wikinaut (talkcontribs)

@all reporters:

If you mean "I want only allow logins with an OpenID from Google as Provider ?", this is possible with the latest version of E:OpenID.

49.176.37.63 (talkcontribs)

Not exactly what I'm looking for. As far as I'm aware there's no way to restrict the openID's to a particular google apps acccount as google app's open id's all come from the google domain, not the domain associated with the apps account.

What would solve this is the ability to confirm accounts before they're allowed access to the wiki, or to have the administrator be the only one who could create the accounts.

Stefan2 (talkcontribs)

At Special:ListGroupRights, you can see that all users have the "createaccount" permission, which allows anyone to create an account. What you want is presumably to change the default permissions so that only administrators have the "createaccount" permission. See Manual:User rights#Manual:User rights for details. If only the administrator can create an account, then the administrator has to go to Special:CreateAccount to create all accounts and then hand over the login credentials to the person who is going to use the account.

RainDelay (talkcontribs)

I would also like to be able to restrict login access to users who are part of my domain hosted on google apps.

Stuartellis (talkcontribs)

I have the same problem as the original poster. OpenID works against our own internal OpenID server, but fails against Google Apps.

We are taking these from Git: MediaWiki 1.21 PHP-OpenID, and the OpenID extension from commit 059ad95fdd945c2156f78dc2d9af085785782963

The host system is Ubuntu 10.04 with Apache 2 and PHP 5.3.2 from packages. We get identical results on Ubuntu 12.04.

Our LocalSettings.php says:

require_once( "$IP/extensions/OpenID/OpenID.php" );
$wgOpenIDTrustRoot = <OUR-SITE>;
$wgOpenIDConsumerForce = https://www.google.com/accounts/o8/.well-known/host-meta?hd=<our-domain.tld>";
$wgOpenIDConsumerStorePath = <PATH>;
$wgOpenIDServerStorePath= <PATH>;
$wgOpenIDUseEmailAsNickname = true;
$wgOpenIDTrustEmailAddress = true;
$wgOpenIDConsumerAndAlsoProvider = false;
$wgOpenIDAllowAutomaticUsername = true;
$wgOpenIDShowUrlOnUserPage = "never";
$wgWhitelistRead = array("Special:OpenIDLogin", "Special:OpenIDFinish");
$wgOpenIDLoginOnly = true;
$wgOpenIDAllowServingOpenIDUserAccounts = false;

The error just reports that PEAR_Error is not loaded:

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
Profiler::instance called without $wgProfiler['class'] set, falling back to ProfilerStub for safety
Connected to database 0 at localhost
Fully initialised
Connected to database 0 at localhost
MessageCache::load: Loading en-gb... got from global cache
Title::getRestrictionTypes: applicable restrictions to Main Page are {edit,move}
ContentHandler] Created handler for wikitext: WikitextContentHandler
Unstubbing $wgLang on call of $wgLang::getCode from MessageCache::get
IP: <REMOVED-FROM-QUOTE>
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser
Parser: using preprocessor: Preprocessor_DOM
Use of User::getSkin was deprecated in MediaWiki 1.18. [Called from OpenIDHooks::onPersonalUrls in <PATH>/extensions/OpenID/OpenID.hooks.php at line 90]
Class PEAR_Error not found; skipped loading
OutputPage::sendCacheControl: no caching **
Reply to "OpenID with Google Apps"
Allcarwiki (talkcontribs)

I've been having trouble getting OpenID to work for my wiki, it's installed fine, displays fine, you get re-directed to the google/yahoo/etc login page fine, but once you've logged in and allowed access, the redirect back is to a 404: Page Not Found, which then causes the log in to fail.

The only thing I've been able to come up with is something like this: http://drupal.org/node/576270

But it doesn't seem to help me much as I'm not clear on what to do. Anyone else had this issue and resolved it?

This post was posted by Allcarwiki, but signed as 115.64.32.238.

Allcarwiki (talkcontribs)

Never mind, ended up working. Not sure how but it fixed itself over the last few weeks. Could've been my host but likely was an update of the database or something.

Reply to "404: Page Not Found [SOLVED]"

OpenID login and return links don't use short URL [SOLVED]

2
Terminus~mediawikiwiki (talkcontribs)

How do I get the OpenID login link in my sidebar, and the return link, to be under the short URL http://my.domain/wiki/ rather than http://my.domain/w/index.php? I already have all the rest of my pages under http://my.domain/wiki/ by following the short URL instructions, but the OpenID login link and the return link aren't. This causes a problem because the default TrustRoot is http://my.domain/wiki/, which mis-matches with the return link. I tried changing the TrustRoot to http://my.domain/w/index.php, but that caused more problems because of URL-encoding of the ? that appeared in the return link... this confused the Janrain library.

MediaWiki 1.15.5-1 PHP 5.3.3-1ubuntu9.5 (apache2handler) MySQL 5.1.49-1ubuntu8.1 OpenID (Version 0.8.4dev)

This post was posted by Terminus~mediawikiwiki, but signed as Terminus.

Terminus~mediawikiwiki (talkcontribs)

Never mind, I found that setting the TrustRoot just to http://my.domain/ fixed the problem. Don't know why I didn't think of trying that earlier. It might be wise to add this to the documentation though.

This post was posted by Terminus~mediawikiwiki, but signed as Terminus.

Reply to "OpenID login and return links don't use short URL [SOLVED]"

[SOLVED] OpenID: no auth_request

5
Summary by Wikinaut

Solution: make sure that your PHP has the php-xml module available or is compiled with option --with-xml .

Wikinaut (talkcontribs)

After I migrated to a new hosting provider, the OpenID extension stopped working.

This message appears on the page after I try to log in:

Verification error
An error occured during verification of the OpenID URL.

And this appears on the log file:

OpenID: no auth_request

You can try for yourself at http://openfarmtech.org/w/index.php?title=Special:OpenIDLogin

What could be causing this? --Elifarley 10:35, 28 March 2011 (UTC)

The "Verification error" message of the OpenID extension is admittedly not very specific. What is the consumer and what is the provider for the OpenID authentication you wanted to make? --Wikinaut 20:52, 28 March 2011 (UTC)
I was trying to use GMail to authenticate at openfarmtech.org --Elifarley 02:03, 29 March 2011 (UTC)
Codehead (talkcontribs)

I see you've been able to solve this issue. What was the problem and how did you fix it? --Codehead 12:05, 14 June 2011 (UTC)

Wikinaut (talkcontribs)

Codehead,

I did not receive any further information from the original submitter, Elifarley. If you have a similar problem, please do me a favour and

  • check the First aid checklist on top of this page
  • post a new thread or contact me by wiki mail.

Perhaps I can help. If possible: use MediaWik trunk and OpenID trunk versions.

ErikDeBruijn~mediawikiwiki (talkcontribs)

I also get no_auth_request, also with non https endpoints. To be sure I've upgraded openssl, removed SSL certicate checks and it responded the same, so I don't think they were used yet. I've tried it on different versions of mediawiki and the corresponding version of the wiki (1.16.5 (r91224) a.t.m. and also 1.16.2). I tried using a different store (other than file), but then it reports an error even though I ran "php update.php".

In the log I see:

when choosing google: OpenID: no auth_request (because $auth_request === null)

when choosing flickr and being returned after logging in: OpenID: aborting in auth because no response was recieved


I do get an object in $customer, and there are response headers, too. So it seems to contact external servers.

I also managed to contact Elifarley whom I know by coincidence, he said he fixed it by migrating servers. His problem could be related to SSL, but it could be many things if the entire environment changed.

Apparently this: $auth_request = $consumer->begin( $openid_url ); returns null in SpecialOpenID.body.php on line 213, but I cannot change this even if I return true at the beginning of Auth_OpenID_Consumer's->begin() in "Auth/OpenID/Consumer.php"!


I'm at a loss. I spent over 6 hours trying to figure this one out!! Please let me know what else I could try...

This post was posted by ErikDeBruijn~mediawikiwiki, but signed as ErikDeBruijn.

Hsand01 (talkcontribs)

I spent hours trying to figure this out. Apparently RHEL 5.7 by default does not install the php-xml extension. I simply ran this and restarted apache.

yum install php-xml
Reply to "[SOLVED] OpenID: no auth_request"

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"

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?"

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]]"

Verification error: Cert Verification fails [SOLVED]

3
Wikinaut (talkcontribs)
Verification error
An error occurred during verification of the OpenID URL. 

I am receiving this error when trying to login using my OpenID account with any https site. Basically I've found out that its trying to verify my CAfile: /etc/pki/tls/certs/ca-bundle.crt

How can I mitigate this? I was thinking I could either setup php.ini to use curl -k? (which I dont know how to)

Or I could setup the ca-bundle.crt cert (which i already have a ca.crt file setup for another site hosted on the same machine) Anyone know how to setup the ca-bundle.crt?

Anyone know how to get around this?

error_log http file:

CURL error (60): error setting certificate verify locations:
 CAfile: /etc/pki/tls/certs/ca-bundle.crt
 CApath: none
 referer: http://mysite.net/index.php?title=Special:OpenIDLogin&returnto=Home

FYI: I resolved this issue by making /etc/pki/tls/certs/ readable.

Reply to "Verification error: Cert Verification fails [SOLVED]"

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"