The scenario with shared user tables and no SSO is second best, but perfectly acceptable.
Now for the inter-wiki API authorization. On https://www.mediawiki.org/wiki/API:Login#How_to_log_in 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 you."
So the question is, what framework or HTTP request library is that and how can it be used.
Do you have an idea what that could be?
Ad
On 6 Oct 2016, at 20:11, Mark A. Hershberger mah@nichework.com wrote:
Ad Strack van Schijndel writes:
Does the enterprise you are hosting these for have an SSO source like Active Directory?
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.
Cindy 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...
In the meantime I have tried OAuth 'Owner-only consumers' https://www.mediawiki.org/wiki/OAuth/Owner-only_consumers#PHP
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 CentralAuth.
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 tried this.
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 a consumer.
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.
-- Mark A. Hershberger NicheWork LLC 717-271-1084
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise