I double checked the Short URL manual page , because you mentioned that
you planned to switch to short URLs due to this issue. We do not use short
URLs, so there must be something else going on. What struck me on the
manual page, was the following:
MediaWiki's default page addresses looks like these examples:
http://example.org/w/index.php/Page_title *(recent versions of MediaWiki,
http://example.org/w/index.php?title=Page_title *(recent versions of
MediaWiki, with CGI support)*
Our URLs are consistent with the first case and yours are consistent with
the second. However, we do have CGI enabled. Maybe somebody on the list can
elaborate on why the format of the URLs might be different?
Regardless, the best fix for this situation would be for the OpenID Connect
library used by the extension not to strip off the URL parameters. Yes, please
report the second bug you found in the OpenID Connect library directly on
the GitHub page for that library. While you are at it, you could also
report the bug/feature that strips the URL parameters off the redirect URL. In
the meantime, I will add some text to the OpenID Connect extension page
indicating the known bug.
Date: Fri, 9 Dec 2016 14:48:01 -0600
> From: Scott Koranda <skoranda(a)gmail.com>
> To: mediawiki-l(a)lists.wikimedia.org
> Subject: Re: [MediaWiki-l] OpenID Connect extension and redirect_uri
> Message-ID: <20161209204801.GA59479(a)paprika.localdomain>
> Content-Type: text/plain; charset=us-ascii
> > You are correct: the redirect_uri parameter should be pointing back to
> > Special:PluggableAuthLogin. From your example below, it should look
> > something like:
> > redirect_uri=https%3A%2F%2Fmyserver.org%2Fw%2Findex.php
> > %2FSpecial%3APluggableAuthLogin
> > The redirect_url is computed by the code at , which discards all query
> > parameters. As long as you are being redirected to OIDC from
> > https://myserver.org/w/index.php/Special:PluggableAuthLogin, you should
> > fine. If you are being redirected from
> > https://myserver.org/w/index.php?title=Special:PluggableAuthLogin,
> > the title would be stripped off.
> > PluggableAuth is redirected from Special:UserLogin to
> > Special:PluggableAuthLogin by creating the URL at  using
> > Title::newFromText( 'Special:PluggableAuthLogin' )->getFullURL()
> > and then being redirected to it. Could getFullURL() be generating the URL
> > in "?title=..." form on your server? Perhaps because of ? If so,
> > let me know. There would have to be a fix to prevent the title query
> > parameter from being stripped.
> Thank you Cindy. That was the hint I needed.
> Although I have experience with OIDC I am new to MediaWiki and
> I had not yet configured "short URLs". After making the
> necessary changes in my Apache HTTP Server and MediaWiki
> configurations to support short URLs the extension then began
> to generate a correct redirect_uri value.
> Should the use of short URLs be mentioned as a requirement for
> the OpenID Connect extension, or is it the case that not using
> short URLs is so rare as to not warrant mentioning it
> I now have the extension interoperating with my desired OP
> (not Google FWIW). I did, however, find a small bug.
> The OP returns an authorization code value that is a URI. As
> such it is URL-encoded in the POST body being sent back to the
> extension. The extension, however, does not URL-decode the
> value so when it later attempts to exchange the code for the
> ID token it correctly URL-encodes the code but now it is
> "double encoded" and rejected by the OP.
> It appears that this is really an issue in the OpenID Connect
> PHP library that the OpenID Connect extension includes. Should
> I open an issue directly with that project or as the extension
> author would you prefer to do that? Or should I just open an
> issue for the OpenID Connect extension?
> Scott K
> Subject: Digest Footer
> MediaWiki-l mailing list
> End of MediaWiki-l Digest, Vol 159, Issue 7
Apologies for the cross-posting. Please help spread the word!
Dear MediaWiki admins, developers, and users. We are excited to bring you
the Enterprise MediaWiki Conference this Spring in McLean, VA. To make the
best event possible, we need your help! Please propose a talk on the event
Suggested topics for talks include:
* Examples of use of MediaWiki in organizations
* Lessons learned and challenges in the use of MediaWiki and MediaWiki
extensions in organizations
* Gamification and other incentives for wiki contributions
* Wikitext patterns and wiki design patterns
* Wiki development frameworks
* MediaWiki extension usage and development
* New extensions, extension updates, and ideas for future extensions
For inspiration, see last year’s presentations. 
Please do add a title, a brief description and your name. If you don’t have
a full abstract prepared at this time we’ll contact you as the event
If you have a full presentation ready (you overachiever you!) feel free to
create a page and add a link.
Presentations will be recorded and made available after the conference.
== Registration ==
Registration for EMWCon is now open!  Tickets are on sale through
Eventbrite. There is a discount rate for students and freelancers
available. This rate ends on 25 January.
== Important Facts =
Dates: 8-10 March 2017
Location: McLean, VA, USA at MITRE, a not-for-profit organization that
manages Federally Funded Research and Development Centers (FFRDCs)
sponsored by the US federal government.
If you have any questions please feel free to reach out. Thank you for your
interest and I hope to see you in the Spring!
We are currently using MW 1.26.2. After we login to MediaWiki, the monobook skin displays the
login name in the upper right hand corner. We would like to display the Real Name from the user's
preferences instead. We don't want to rename the profile or anything, it's just this one little place
where we would like to see the Real Name up in the corner of the skin there.
Does anyone know of a simple hack to do this for this version?
You are correct: the redirect_uri parameter should be pointing back to
Special:PluggableAuthLogin. From your example below, it should look
The redirect_url is computed by the code at , which discards all query
parameters. As long as you are being redirected to OIDC from
https://myserver.org/w/index.php/Special:PluggableAuthLogin, you should be
fine. If you are being redirected from
the title would be stripped off.
PluggableAuth is redirected from Special:UserLogin to
Special:PluggableAuthLogin by creating the URL at  using
Title::newFromText( 'Special:PluggableAuthLogin' )->getFullURL()
and then being redirected to it. Could getFullURL() be generating the URL
in "?title=..." form on your server? Perhaps because of ? If so, please
let me know. There would have to be a fix to prevent the title query
parameter from being stripped.
> I am using MediaWiki version 1.27.1 with the OpenID Connect
> extension detailed at
> I have configured the extension and when I click on "Log in" I
> am taken to
> There I click on "Log in with PluggableAuth" and I am
> redirected to the OIDC OP as I expect.
> I noticed, however, that when the extension computes the
> redirect_uri parameter that it includes when it redirects the
> browser to the OP it is
> That surprises me. I would have thought that the redirect_uri
> would be to a page where MediaWiki can consume the
> authorization code that is returned by the OP.
> After I authenticate with the OP it redirects the browser back
> to the redirect_uri with an authorization code and the correct
> state but then MediaWiki just returns a '200 OK' and the main
> page of the wiki.
> It naively appears to me that the redirect_uri being sent to
> the OP is not correct, but I do not see a way to configure the
> extension to override it, and I would not know what value to
> I appreciate any input people have on what I might be doing
> wrong, or how I can further troubleshoot.
> Scott K
I try to login and create my account I get an error.
Auto-creation of a local account failed: Automatic account creation is not allowed.
Using the admin account I get the same error.
Has anyone figured out how to get this to work in MediaWiki 1.28.0?
A am currently working on an account creation throttle filter for a private
wiki. using the *action == 'createaccount' *filter I have been able to
successfully limit spam account creations. Is there a way to check the IP
address of someone creating the account to a whitelist so that if there is
a match the filter is ignored? The closest I am seeing is the ip_in_range which
still requires that an IP address be provided.