Extension talk:OpenID/Archive 3

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.

Previous page history was archived for backup purposes at Extension talk:OpenID/LQT Archive 1 on 2015-07-10.

FOR MORE LANGUAGE!

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

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

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?

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?

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.

Hi all,

We have a Mediawiki site for our dev environment and we have not used this in a while. Now when we tried to login, we are getting this kind of page(below) instead of the SAML authentication page. Am not sure but i guess this issue might be related to this topic. Can anyone please help me with this

Thanks & Regards,

Sethu

Login required

Jump to: navigation, search

Please log in to view other pages.

Retrieved from "https://mywikisite/mediawiki-1.23.5/index.php?title=Special:Badtitle"

Navigation menu

Personal tools

• 127.0.0.1
• Talk for this IP address
• Log in

Namespaces

• Special page

If you have set-up the wiki so that not _only_ OpenID-logins are allowed, but also "normal" password-based logins, I suggest to simply disable the OpenID-extension and try again.

If you don't know the password, use the "I forgot my password" function to reset that account via mail.

I hope this helps.

By the way, I think, the OpenID-extension should be retired in the near future for many reasons.

Is it possible to skip the "Verification succeeded" page and redirect a user to whereever he was before (= the page in the "Return to ..." link)?

Maybe this page is useful in some cases, but in my setup it's useless (I enforce a specific openID provider, disallow username/password logins, and users have to set/change their mail address in the openID provider, not in mediawiki. This means the link to the OpenID user preferences (actually I hide the OpenID-specific settings to make sure nobody unticks the "email address from openID" checkbox) and the hint about the account password are superfluous.

Being able to skip the "Verification succeeded" page would save my users an useless click each time they login ;-)

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.

Where do we enable that?

how can i get /etc/pki/tls/certs/ readable.

http://localhost/letzride/

filed as bug44819: 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

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

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

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.

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.

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)

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.

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

Seconded. I need this also.

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

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.

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.

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

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

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.

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.

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.

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.

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

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)

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)

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.

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.

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

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

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