Extension talk:OpenID

From MediaWiki.org
Jump to: navigation, search
An archive box Archives 

Archive 1 - Archive 2

It is preferred that you open a regular bug report for new issues.
Warning 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[edit | edit source]

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.

Warning 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():


is support installed for this?

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
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 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?
/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.

Start a new discussion
First page
First page
Previous page
Previous page
Last page
Last page

OpenID 2.0 for Google Accounts has gone away

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

Golom4433 (talk)17:16, 28 April 2015

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

John Broughton (talk)16:59, 12 May 2015

OpenID extension doesn't work at all?

Edited by another user.
Last edit: 12:00, 14 April 2014


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
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
CACHES: EmptyBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser]
[cookie] session_set_cookie_params: "0", "/", "", "", "1"
LocalisationCache: using store LCStore_DB
Fully initialised
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?, 10 April 2014

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

Wikinaut (talk)18:42, 10 April 2014

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?, 11 April 2014
  • 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.

Wikinaut (talk)20:20, 11 April 2014

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

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.

Wikinaut (talk)11:59, 14 April 2014

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!!

Jskang (talk)08:18, 23 July 2014

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

23:51, 11 September 2013

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.

Wikinaut (talk)06:58, 12 September 2013

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.

05:30, 16 September 2013

This problem is filed as Bug 34357.

Wikinaut (talk)06:03, 16 September 2013

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"

Gleki.arxokuna (talk)07:09, 23 January 2014

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.

Wikinaut (talk)07:15, 23 January 2014

Verification error: Cert Verification fails [SOLVED]

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.

Wikinaut02:59, 30 May 2011

Where do we enable that?, 30 April 2014

how can i get /etc/pki/tls/certs/ readable., 28 May 2014

How to use/store given URL instead of delegate URL

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?

Psmay (talk)21:07, 10 April 2014

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.

Wikinaut (talk)21:16, 10 April 2014

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

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
: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

Go2dev (talk)14:53, 17 March 2014

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...

Atao60 (talk)16:55, 28 March 2014

[SOLVED] https site and Special:Badtitle

- 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 (talk)10:21, 22 March 2014

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?

Atao60 (talk)11:11, 23 March 2014

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?

Wikinaut (talk)06:51, 26 March 2014

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.

Atao60 (talk)08:49, 26 March 2014

[SOLVED] $wgOpenIDTrustRoot

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

[[kgh]] (talk)15:10, 16 November 2013

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

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 (talk)08:42, 2 October 2013

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).

Jskang (talk)09:12, 7 January 2014

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

Wikinaut (talk)07:41, 8 January 2014

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.

Jskang (talk)17:06, 13 January 2014

OpenID with Titleblacklist

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

Myrtonos (talk)04:26, 18 October 2013

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.

Wikinaut (talk)05:01, 18 October 2013

Pitfall of this extension

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 (talk)21:51, 15 October 2013

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.

Rob Kam (talk)15:39, 16 October 2013

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

Wikinaut (talk)22:00, 16 October 2013

OpenID with Google Apps

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.

Okthen (talk)06:28, 9 July 2012

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

Seconded. I need this also.

ahowden[at]howdenfitness[dot]com00:00, 13 June 2013

@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.

Wikinaut (talk)07:32, 13 June 2013

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.

andrewhowden[at]howdencompany[dot]com03:24, 10 July 2013

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.

Stefan2 (talk)10:02, 10 July 2013

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

RainDelay (talk)16:52, 15 July 2013

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
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 **
Stuartellis (talk)12:22, 1 August 2013

DIsallow non-OpenID at a later date

Hi, is it possible to allow non-OpenID registration for now and disable it + require everybody to associate themselves with an OpenID account later?

Tyteen4a03 (talk)23:33, 22 July 2013

Existing account login + OpenID account creation

I have this extension installed on my wiki, but there are a large number of users who don't have an OpenID associated with their account. Is it possible to configure the extension to allow existing users to log in with their name/password, but force new users to create an account using OpenID?

Setting $wgOpenIDLoginOnly = false still allows account creation without OpenID, but the setting I used in the past to prevent account creation, $wgGroupPermissions['*']['createaccount'] = false, stops new users from creating new IDs., 12 July 2013

Good idea. Please can you file a bug (severity=enhancement) with this title and content in our bugtracker https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=OpenID ? This helps you and us to track the progress of implementation.

Thanks in advance.

Wikinaut (talk)07:55, 13 July 2013

What version should I download?

The instructions are not at all clear. It seems my options are:

  • Download a tag. But I think, the OpenID extension doesn't have any tags
  • The latest version of one of the extensions branches. But the comments say these might be unstable. That gives me the heebie-jeebies -- I really want a stable version.
  • A snapshot made during the release of a MediaWiki version. This also says it might be unstable.
  • clone from git. But the master branch of the git repo seems to be under (very) active development, so I'm assuming it, too, will be unstable.

I have MediaWiki 1.19 installed on my server. That's not listed in the compatibility table.

What should I do? Thanks for any advice!

Klortho (talk)00:48, 18 April 2013

I recommend to use the latest MediaWiki from git and the latest OpenID version from git.

Wikinaut (talk)22:20, 6 May 2013

[RESOLVED/INVALID] Is it possible to change the expiration of the session/cookie for logged-in users?

Users are logged out pretty quickly after their session goes idle. Is there a way to force the login session to remain open longer?

Shifuimam (talk)14:31, 3 April 2013

This is not an issue of the OpenID extension.

Wikinaut (talk)10:46, 11 April 2013

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

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

UnwashedMeme (talk)21:18, 18 January 2013
  • 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 ?
Wikinaut (talk)22:41, 18 January 2013

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.

UnwashedMeme (talk)20:49, 22 January 2013

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.

UnwashedMeme (talk)16:50, 23 January 2013

[SOLVED] ConfirmAccount extension and OpenID extension

Hi, i have had a running setup of Mediawiki: 1.19.1 PHP Version 5.3.3 OpenID: 1.004.

I wanted to have control of the user account creations and so tried the AccountConfirm extension. However, the extension did not seem to work together with the OpenID extension. So I removed it again. Since then, when going through and finishing the login process at Special:OpenIDLogin, I am not logged in on mediawiki anymore. On the "Verification Success" page of the login process it says "Successful verification and log in as user", so the user name is not given there. My LocalSettings.php is as before and I could not find any errors indicating to the problem in the log file. If I use the regular login (without OpenID) I can login and create accounts fine.

How can I make my setup work as before again?

What possibility exists with the OpenID extension to confirm accounts before their creation? I only know of the $wgOpenIDConsumerAllow

Thanks, 7 November 2012

The problem was that I had removed the user account manually from the user table. I found that there was still an entry in the user_openid table with an openId that I wanted to use to login. After the removal of this entry everything works fine again., 7 November 2012

First attempt to edit new user page shows red message "<User id> is not registered"

After logging in a new user with OpenID (Google account), the first attempt to edit the User page shows a message in large red letters "<User id> is not registered". Later, after closing session, the message is gone. This has confused some of our new contributors.

Can this misinformation be corrected? --Fred, 22 August 2012

I have never seen this. Please go through the First aid checklist on top of this page, thanks,

Wikinaut (talk)22:26, 22 August 2012

CAVEAT: Google's OpenIDs are Unique Per-Domain

Hi, we're using version 0.9.0 patched (as described here) to work with MediaWiki 1.17.2. Using Google as OpenID provider it worked like a charm until we changed subdomains on the Wiki server (foo.example.com --> bar.example.com). The login itself succeeded but the user was presented with a form where he should choose his user name. We found out that $user = self::getUser( $openid ); in SpecialOpenIDLogin.body.php failed to return a valid user object since $openid was not found in the user_openid table! After switching back to foo.example.com the login worked again as expected. A bit of googling revealed the reason: Google's OpenIDs are Unique Per-Domain. We implemented a rather hackish way to update OpenIDs in the database for the time of the migration. Basically: Be very careful when changing domains when using Google as OpenID provider. Is the SVN version able to work with Google's changing OpenIDs?

Pigpen (talk)14:31, 22 June 2012

Thanks for reporting this issue. I already knew the problem, for example from this report https://drupal.org/node/1223386 .

You asked "Is the SVN version able to work with Google's changing OpenIDs?". Answer: no, currently not, but the SVN version allows users with an OpenID account to associate a normal password to the account, which was not possible in older OpenID versions. This can at least help to overcome (wiki) domain move problems.

Wikinaut (talk)21:28, 22 June 2012
First page
First page
Previous page
Previous page
Last page
Last page