The scenario with shared user tables and no SSO is second best, but perfectly acceptable.
Now for the inter-wiki API authorization. On
it says "Note that logging in
and remaining logged in requires correct HTTP cookie handling by your client on all
requests. Typically your framework or HTTP request library will handle this for
So the question is, what framework or HTTP request library is that and how can it be
Do you have an idea what that could be?
On 6 Oct 2016, at 20:11, Mark A. Hershberger
Ad Strack van Schijndel writes:
enterprise you are hosting these for have an SSO source like
No, this is for our own company. First attempts on this road.
Would it be an idea to have a shared user table for all wiki's?
The shared table would work, but it wouldn't give you SSO. Typically,
SSO requires some kind of service like Microsoft's AD, Amazon's AWS
Directory Service, or a Kerberos infrastructure.
Cicalese has just finished updating PluggableAuth for MW 1.27. I
think it would prove very helpful to you.
Mmm, at first glance it seems that situation where PluggableAuth is
especially useful is not ours. And I wouldn't know how to use it. I'm
more the 'use extensions as-is' kind of guy :-).
If you had a way to work with SAML, it would just work, but...
Ah, I hadn't seen that. That looks like the approach you want if you to
have a set-up like the WMF's.
To continue, though, I think you'd really need CentralAuth, but as that
extension's page notes:
Warning: CentralAuth was designed specifically for Wikimedia...
If you are starting a new wiki farm from scratch ... it is much
easier to set up global accounts using $wgSharedDB rather than using
However, this provides no solution to the single-sign-on feature
(sign-in on one wiki, like wikipedia.org
, automatically makes the
user signed-in to e.g. a shared repository under a different, shared
domain, like commons.wikimedia.org
), nor global account locking.
So, unless you're prepared to tie yourself to WMF's code roll-outs, I
would avoid CentralAuth.
So, you're stuck with shared tables, and that means you have no SSO.
You *might* be able to do something to make SSO work by setting
$wgSharedTables, $wgSharedPrefix, and/or $wgCookiePrefix, but I haven't
Added this code to James's QueryResultFetcher
in what I figured would
be the right place. With the values I got when registering the wiki as
See, this looks like an interesting problem. Even with the above work
you wouldn't have the inter-wiki API authorization set up (unless that
all happens via JS).
Mark A. Hershberger
Mediawiki-enterprise mailing list