FOR MORE LANGUAGE!
Extension talk:OpenID
- 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.
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.
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.
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