CentralAuth global session doesn't include some *.wikimedia.org public wikis
Closed, ResolvedPublic

Description

I realized that when I login after SUL, I still need to login separately in Wikispecies. The page after I logged in showed various WMF projects' symbol but Wikispecies is not there. Is Wikispecies forgotten (once again)?


Version: unspecified
Severity: normal

bzimport set Reference to bz14407.
OhanaUnited created this task.Via LegacyJun 4 2008, 3:53 PM
tstarling added a comment.Via ConduitJun 7 2008, 1:37 AM

The login system is such that it requires users to wait at the login screen while they are logged in to all relevant domains. Due to security issues, we can't log users in to *.wikimedia.org (where Wikispecies is located), so we have to log users in to the third-level domains individually. I added Meta and Commons to the list due to their high traffic transferring from other wikis. There are 32 wikis on *.wikimedia.org which are excluded, plus www.mediawiki.org. There's a clear incentive to draw the line somewhere, and that's where I've drawn it.

OhanaUnited added a comment.Via ConduitJun 7 2008, 2:23 AM

(In reply to comment #1)

The login system is such that it requires users to wait at the login screen
while they are logged in to all relevant domains. Due to security issues, we
can't log users in to *.wikimedia.org (where Wikispecies is located), so we
have to log users in to the third-level domains individually. I added Meta and
Commons to the list due to their high traffic transferring from other wikis.
There are 32 wikis on *.wikimedia.org which are excluded, plus
www.mediawiki.org. There's a clear incentive to draw the line somewhere, and
that's where I've drawn it.

Then would it be possible to add species.wikimedia.org to the list? I don't want to see it forgotten or fallen through the cracks.

brion added a comment.Via ConduitJun 11 2008, 9:03 PM
  • Bug 14509 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJun 11 2008, 9:20 PM

Wiki.Melancholie wrote:

Maybe add a checkbox at [[Special:UserLogin]] for optionally logging in on all Wikimedia wikis.

bzimport added a comment.Via ConduitJul 6 2008, 9:48 AM

brianna.laugher wrote:

May wikimania2008 be added, please? It's happening soon and as a one-off event people are very unlikely to want the benefits of signing up separately.

bzimport added a comment.Via ConduitJul 6 2008, 7:14 PM

bugs wrote:

(In reply to comment #5)

May wikimania2008 be added, please? It's happening soon and as a one-off event
people are very unlikely to want the benefits of signing up separately.

You don't have to sign up separately for any of the Wikimania wikis, they are just not on the global *cookie* session (auto-login).

bzimport added a comment.Via ConduitJul 11 2008, 1:14 AM

D.U.Thibault wrote:

Add me to the list of those that would like to have at least the option of including Wikispecies to the SUL.

siebrand added a comment.Via ConduitAug 16 2008, 11:01 PM

Closing this issue as WONTFIX. It is a cost vs. benifits issue, and in comment 1 Tim explains that the line has to be drawn somewhere.

OhanaUnited added a comment.Via ConduitAug 16 2008, 11:40 PM

I am reopening this bug.

Certainly it can be fixed, plus the majority of the people that commented in here wish to see a few more popular projects get included. Look at it this way, the main sister projects are listed on the Main Page of Wikipedia, yet Wikispecies is not logged in automatically. Even Wikisource gets SULed and its size is similar to Wikispecies. As seen in http://wikimediafoundation.org/wiki/Our_projects, Wikispecies is the only project that does not receive the same treatment in SUL. Judging from such actions, does that mean Wikispecies project is not as good as others so it doesn't deserve the attention and a chance to get SUL linked up?

bzimport added a comment.Via ConduitAug 17 2008, 11:40 PM

D.U.Thibault wrote:

Could we get a better explanation of the costs involved? The comment by Tim refers to "security issues" and mentions "third level domains" (which are...what?), but there is no mention of what the *cost* of including Wikispecies et al. may be. If you give a clear explanation of alleged costs, then most people will likely opine. But as it stands all we bystanders have are some vague hand-waving arguments with a whiff of arrogance about them.

Platonides added a comment.Via ConduitAug 18 2008, 10:56 AM

Due to security issues, we can't log users in to *.wikimedia.org (where Wikispecies is located),

That's because not all content on *.wikimedia.org is trusted. There was some wikimedia.org subdomains not directly run by the WMF servers, and upload.wikimedia.org pose a threat opn future vulnerabilities. You could have XSS due to a bad-behaved browser thinking a specially crafted image was html, or the recent discussion in wikitech-l and commons-l about GIFAR, which the domain separation avoids.

so we have to log users in to the third-level domains individually.

Instead of automatically login to any domain at wikimedia.org people needs to be logged in into meta.wikimedia.org, commons.wikimedia.org... Ie. one image per project.

I added Meta and Commons to the list due to their high traffic transferring from other wikis.
There are 32 wikis on *.wikimedia.org which are excluded, plus www.mediawiki.org. There's a clear incentive to draw the line somewhere, and that's where I've drawn it.

The cost would be loading 41 images on each login or logout instead of 9. Plus the handling of those requests, session setup, image sending, etc.

Perhaps the solution could be a new top-level domain to store the untrusted images, like wikimediaimages.org?

bzimport added a comment.Via ConduitAug 18 2008, 12:00 PM

jelle.zijlstra wrote:

Thank you for your explanation, Platonides. I am, however, not sure why there should actually be 41 images on the login page, as no one has asked that the feature be turned on for all *.wikimedia.org wikis. In my opinion, Wikispecies is clearly a prime candidate for inclusion, as it is a separate Wikimedia project, not a test wiki, temporary or organizational, as most *.wikimedia.org wikis are. I am of course wholly unfamiliar with the technical details of CentralAuth, but I do not expect that adding a single site will have such a detrimental effect as adding 32.

siebrand added a comment.Via ConduitAug 18 2008, 12:12 PM

Quoting Tim from comment 1: "There's a clear incentive to draw the line somewhere, and that's where I've drawn it."

It's not only Species. Wikis that also 'deserve' (POV, not necessarily supported by me, but just making the point to support Tim's descision) to be included are: the latest Wikimania, Incubator, betawikiversity, mediawiki.org, quality, advisory board wiki. So that's 6 instead of one. Why only add one, not all 6?

bzimport added a comment.Via ConduitAug 18 2008, 3:13 PM

suicidal.hamster wrote:

I would have thought http://wikimediafoundation.org/wiki/Our_projects would show why Wikispecies 'deserves' to be included and why it is very different to all the other *.wikimedia.org (excluding commons which is already included).

bzimport added a comment.Via ConduitAug 18 2008, 9:46 PM

evula wrote:

Wikispecies is decidedly a major Foundation project. Suggesting that it is more akin to other *.wikimedia.org sites, like otrs-wiki, spcom, or chapcom, would be laughable if it wasn't simultaneously insulting.

Though I wouldn't suggest removing it from SUL, I can't begin to understand why the MediaWiki site would be "more" of a Foundation project than Wikispecies.

bzimport added a comment.Via ConduitSep 14 2008, 2:54 AM

jus168jih wrote:

Recently, multilingual Wikisource wikisource.org seems to be disconnected from the global log-in.

bzimport added a comment.Via ConduitNov 12 2008, 6:08 AM

wing.philopp wrote:

It there a possibility to move Wikispecies in a domain that can be easily included into SUL and redirect the origical spezies.wikimedia.org to that new domain? I agree that species is an important WikiMedia project and should be treated equaly as other projects like WikiSource, WikiNews, Wiktionary and Wikipedia.

bzimport added a comment.Via ConduitNov 16 2008, 6:32 PM

mike.lifeguard+bugs wrote:

(In reply to comment #17)

It there a possibility to move Wikispecies in a domain that can be easily
included into SUL and redirect the origical spezies.wikimedia.org to that new
domain? I agree that species is an important WikiMedia project and should be
treated equaly as other projects like WikiSource, WikiNews, Wiktionary and
Wikipedia.

Yes, all content projects should be included here.

bzimport added a comment.Via ConduitNov 17 2008, 8:22 PM

evula wrote:

(In reply to comment #17)

It there a possibility to move Wikispecies in a domain that can be easily
included into SUL and redirect the origical spezies.wikimedia.org to that new
domain? I agree that species is an important WikiMedia project and should be
treated equaly as other projects like WikiSource, WikiNews, Wiktionary and
Wikipedia.

Wikispecies is a language-independent project; there will never be language subdomains like there are for Wikipedia, Wikisource, et al, and it doesn't stand on its own in the same regard as mediawiki.org. A separate domain for the project isn't warranted.

Commons and Meta are both language-independent projects as well, and while Wikispecies may not have the same importance in the WMF umbrella, it should still be included in SUL.

brion added a comment.Via ConduitDec 1 2008, 11:56 PM

Added species to the session setup list per request.

I don't want to go too crazy with the rest yet; might want to just think about better ways to arrange some of the domains, or whether we can consider the cookie issue reasonably well fixed at this point and just do a wildcard cookie on *.wikimedia.org.

With HttpOnly cookies being used, most modern browsers won't be allowing XSS code to hijack the session cookie, so it would only be accessible to actual web apps on those servers (eg a PHP execution vulnerability). (Of course some browsers still don't support HttpOnly cookies...)

bzimport added a comment.Via ConduitJun 27 2009, 10:43 PM

mike.lifeguard+bugs wrote:

(In reply to comment #20)

Added species to the session setup list per request.

Changed summary accordingly.

bzimport added a comment.Via ConduitSep 26 2009, 3:33 PM

catlow wrote:

Are meta and Mediawiki supposed to be included? I never seem to be logged in when I go there.

OhanaUnited added a comment.Via ConduitSep 27 2009, 2:08 AM

Meta's definitely included. Not sure about Mediawiki though.

bzimport added a comment.Via ConduitSep 28 2009, 1:06 PM

catlow wrote:

Meta doesn't work for me. Should I report that as a separate bug?

Betacommand added a comment.Via ConduitMay 10 2010, 3:21 PM

Changed title to reflect actual comments and am closing bug as it appears to be fixed

SPQRobin added a comment.Via ConduitMay 10 2010, 7:51 PM

(In reply to comment #25)

Changed title to reflect actual comments and am closing bug as it appears to be
fixed

Revert & reopen, because Incubator still needs to be added. (see #c3)

Catrope added a comment.Via ConduitMay 10 2010, 8:30 PM
  • Bug 20251 has been marked as a duplicate of this bug. ***
Catrope added a comment.Via ConduitMay 10 2010, 8:43 PM

(In reply to comment #27)

  • Bug 20251 has been marked as a duplicate of this bug. ***

bug 20251 comment #8 proposes an alternative implementation that eliminates the need to set cookies on login

bzimport added a comment.Via ConduitJul 21 2010, 4:52 PM

Bryan.TongMinh wrote:

*** Bug 24471 has been marked as a duplicate of this bug. ***

Ragesoss added a comment.Via ConduitJul 21 2010, 5:02 PM

One issue that hasn't been discussed is that the login behavior isn't symmetrical. When you log in to a .wikimedia.org wiki, you get logged in on all the main content wikis, but not vice versa.

It would make more sense to me if the logins were fully separate (if they can't be all integrated), so that signing in with one account on a .wikimedia.org site doesn't automatically log me out of another account on the other wikis.

(See my duplicate bug in comment 29 above for a longer description of why this is weird and confusing.)

bzimport added a comment.Via ConduitOct 1 2010, 6:54 AM

fridaesdoom wrote:

Using a separate browser helps and using the secure server also helps. If I was on Firefox and I login it won't log me in on IE, so on IE I can log into my alternate account for whatever reason and still be on my main account on Firefox, it's the same with the secure server, although I'm not quite sure about the latter.

brion added a comment.Via ConduitFeb 17 2011, 1:25 AM
  • Bug 24471 has been marked as a duplicate of this bug. ***
hashar added a comment.Via ConduitMay 28 2011, 9:30 PM

Adding triage keyword to get this bug talked about during the next meeting.

SPQRobin on IRC asked me to look at it tonight quoting brion as "it should be ok".

I am not wiling to do this on a Saturday evening with no tier-2-support floating around, so I am just bumping this bug :)

SPQRobin added a comment.Via ConduitMay 28 2011, 9:39 PM

To be clear, it is OK to add Incubator. I don't know about the rest of the wikis.

Catrope added a comment.Via ConduitJun 1 2011, 4:23 PM

I was gonna do this after the Berlin conference. Then we got a deployment embargo, an outage, and I took some days off to work on my thesis, so this kinda got left by the wayside.

It's a simple 5-minute job, anyone can do it as long as they're ops backup around.

SPQRobin added a comment.Via ConduitJun 23 2011, 10:49 PM

Priyanka Dhanda added Wikimedia Incubator to the list of wikis for the global login session.

Updated title accordingly (and removed bug 28486 as depending on this bug).

Reedy added a comment.Via ConduitAug 25 2011, 3:14 PM

(In reply to comment #36)

Priyanka Dhanda added Wikimedia Incubator to the list of wikis for the global
login session.

Updated title accordingly (and removed bug 28486 as depending on this bug).

Which are the issues?

SPQRobin added a comment.Via ConduitAug 25 2011, 7:55 PM

(In reply to comment #37)

Which are the issues?

How do you mean, issues?

Reedy added a comment.Via ConduitSep 28 2011, 10:49 PM

I presumably meant what else is outstanding/needs doing?

SPQRobin added a comment.Via ConduitSep 29 2011, 10:43 AM

This bug is about adding wikis that are not in the list of autologin, which includes most *.wikimedia.org. Since the opening of this bug, species.wikimedia.org and incubator.wikimedia.org have been added, so it's probably up to WMF developers to decide whether to add more or close this bug.

bzimport added a comment.Via ConduitMar 6 2012, 11:19 AM

everton137 wrote:

16 people supporting, I have changed to a normal issue, intead of minor. Is that OK?

Solstag added a comment.Via ConduitMar 8 2012, 9:30 AM

Ni!

I'd like to make a priority request, that br.wikimedia.org be immediately included in the autologin list.

The reason for this is very simple and objective: the Brazilian community does not use this wiki as an ordinary chapter wiki; instead, it is used just like any other content wiki and operates in constant collaboration with those.

Anyone, including unlogged contributors, are welcome to edit projects and activities as they will, so it becomes unnatural when editors are forced to login again, and problematic when they forget to login and end up editing with their IP addresses.

Particularly given the proliferation of interwiki links over the years, to and from br.wikimedia, and the fact that one of our missions is ot attract new unexperienced editors.

This has been a constant hurdle for years, as we first reported it as Bug 23151 in April 2010, but we were always hopeful that it would soon get fixed.

However, as that is clearly not the case, and since our community has been scaling up steadily, we'd like to see lifted the increasing weight this imposes on us.

Thank you in advance, and I'm at your disposal for further clarifications.

User:Solstag
.~´

bzimport added a comment.Via ConduitMar 8 2012, 10:07 AM

everton137 wrote:

I second what Solstag said.

Tom

Reedy added a comment.Via ConduitMar 12 2012, 4:11 PM

This is almost a WONTFIX per Platonides and Tim:

Summary: because we have wikimedia.org subdomains not under our control, we can't do a *.wikimedia.org login like we do for other projects. The "fix" would be to load an image per target site that's trusted (tim added a few very common ones), which would end up with 50+ images to be loaded.. :|

At the current setup, that is upto 65 different images, more in future. Meaning probably over 80 images, that's just unacceptable.

Simplifing it down though could be an option. What about if you logged into any pt wikis (ie you use THAT wiki for the login action), we explictly load the br.wm.o image so you get logged in? Same for other relevant projects.

Somewhat of a workaround, and a compromise.

Would need a bit of extra configuration, but shouldn't really be much effort

Platonides added a comment.Via ConduitMar 15 2012, 10:35 PM

A workaround would be to perform the initial login at br.wikimedia.org, taking advantage of its asymmetric nature. This way, you would be logged in everywhere (you care).

Solstag added a comment.Via ConduitMar 16 2012, 1:17 AM

@Sam

Your proposal to load the images when logging in through pt.wikis would be a huge improvement, and we'd be very glad if that could be implemented :)

In the more general case, I have a suggestion, wouldn't it make much more sense to allow all *.wikimedia.org domains and blacklist the few that aren't under WMF control? Even if it takes a bit of hacking in the authentication system, it seems worth it.

@Platonides

Thanks for the idea, but it misses the target, which is making collaboration easier for Wikipedians, who naturally log in through wikipedia, and new users, who we really don't wanna bother with such details.

Ni!

Reedy added a comment.Via ConduitMar 16 2012, 1:47 AM

(In reply to comment #46)

In the more general case, I have a suggestion, wouldn't it make much more sense
to allow all *.wikimedia.org domains and blacklist the few that aren't under
WMF control? Even if it takes a bit of hacking in the authentication system, it
seems worth it.

The only way we can sensibly do that, is to then load an image for each of those safe domains. Which is still going to mean loading 50+ images, which for the generally little benefit, I'm not sure if it's worth the overhead for users

Krinkle added a comment.Via ConduitMar 16 2012, 4:56 AM

(In reply to comment #47)

(In reply to comment #46)
> In the more general case, I have a suggestion, wouldn't it make much more sense
> to allow all *.wikimedia.org domains and blacklist the few that aren't under
> WMF control? Even if it takes a bit of hacking in the authentication system, it
> seems worth it.

The only way we can sensibly do that, is to then load an image for each of
those safe domains. Which is still going to mean loading 50+ images, which for
the generally little benefit, I'm not sure if it's worth the overhead for users

And the additional server side overhead of 50+ extra requests for every user that logs in. And 50 more local account (auto-)creation for each Wikimedia wiki user.

Solstag added a comment.Via ConduitMar 16 2012, 5:38 AM

(In reply to comment #48)

(In reply to comment #47)
> The only way we can sensibly do that, is to then load an image for each of
> those safe domains. Which is still going to mean loading 50+ images, which for
> the generally little benefit, I'm not sure if it's worth the overhead for users

And the additional server side overhead of 50+ extra requests for every user
that logs in. And 50 more local account (auto-)creation for each Wikimedia wiki
user.

I think I was misunderstood, or I was asking for something I did not know was impossible so you're not even considering it. I'm sorry if that's the case.

What I meant was to modify the auth system so you can login every *.wikimedia.org subdomain with a single image/request/whatever, similar to what you already do with *.wikipedia, *.wikinews ..., and then find a way to blacklist only the few subdomains that you don't want to authenticate because they're not under your control, therefore reducing the overhead to the exception not to the rule.

I'm not an authentication expert, so I'm sorry if I'm not helping by just throwing unfeasible ideas.

In case that is indeed impossible...

What are those not-under-control subdomains?

Why can't we move them somewhere else, as has been suggested?

Doesn't that make a lot more sense, as the trend over the years seems to be for SUL integrated *.wikimedia.org subdomains to multiply? (commons, species, incubator, strategy, outreach, wikimanias, more national movement wikis like br.wiki etc)

The chapter wikis, for example, all have got - or should get - their own private domains when their wikis leave the SUL and foundation control, so those can go easily.

Other than that, the only problem I know of is the upload.wikimedia issue discussed earlier in this post, if it still is an issue, but that might just be the one subdomain worth taking the time to move out. :)

Hugs,

ale
.~´

Platonides added a comment.Via ConduitMar 16 2012, 1:27 PM

You can't send a cookie to "all subdomains but a few". You can send it to one subdomain "commons.wikimedia.org, meta.wikimedia.org..." (ie. loading all images), or to all domains *.wikinews.org

Which is why we have to load one image per wiki on wikimedia.org

Maybe we could perform the following:
A login globally sets centralauth_User cookie (only), through a login.domain.org which also set a local login (or through enwiki as done so far).
If receiving a centralauth_User cookie for a wiki but not a centralauth_Token or session cookie (and is not logged out), creates a xywiki_session, set centralauth_Token='requestlogin_session_WYZ' and redirect to https://login.wikimedia.org which acknowledge you are logged in, clear centralauth_Token, enable your session and redirect back.

Note: If login.wikimedia.org doesn't receive centralauth_Token, cookies might be (partially?) disabled. We shall not make a produce loop. Ask the user to either enable cookies or delete them.

This would also be a much stronger login method.
Opinions?

Pine added a comment.Via ConduitMay 30 2012, 10:56 PM

Just noting that I have what I think is the same problem with Outreach. Interestingly, if I log into Outreach first, I can go from there to other project sites, but I can't go from other project sites into Outreach.

bzimport added a comment.Via ConduitMay 30 2012, 11:34 PM

bugs wrote:

(In reply to comment #51)

Just noting that I have what I think is the same problem with Outreach.
Interestingly, if I log into Outreach first, I can go from there to other
project sites, but I can't go from other project sites into Outreach.

That's how it's supposed to work.

There's a separate cookie for each root domain (e.g. wikipedia.org, wikiversity.org) and these all get loaded no matter what site you start your session from. There is no general "wikimedia.org" cookie like this though -- instead each "other project" has its own cookie. Outreach is one of those wikis with a separate cookie, so you only get logged in to outreach.wikimedia.org if you start your session there. In this case, MediaWiki just tacks on the outreach.wikimedia.org login cookie in addition to the wikipedia.org, wikiquote.org, etc. cookies.

Solstag added a comment.Via ConduitMay 31 2012, 4:59 PM

(In reply to comment #52)

(In reply to comment #51)
> Just noting that I have what I think is the same problem with Outreach.
> Interestingly, if I log into Outreach first, I can go from there to other
> project sites, but I can't go from other project sites into Outreach.

That's how it's supposed to work.

Ni!

Just to note that, in the spirit of this bug report, that is not how it is supposed to work, that is just how it was designed to work.

A design that, given the growth of the movement alongside the proliferation of *.wikimedia wikis directly and increasingly relevant to the general public, has become a really annoying bug.

By the way, I take the opportunity to encourage the implementation of the workaround for br.wikimedia mentioned by reedy in Comment 44.

Hugs,

[[User:Solstag]]

Reedy added a comment.Via ConduitJan 15 2013, 3:39 PM

(In reply to comment #53)

By the way, I take the opportunity to encourage the implementation of the
workaround for br.wikimedia mentioned by reedy in Comment 44.

Taking the bug (for now). Will try and look at doing it (from what I remember before it shouldn't be much work), but it likely won't be till after the data centre migration etc.

Reedy added a comment.Via ConduitFeb 3 2013, 2:05 AM

(In reply to comment #46)

@Sam

Your proposal to load the images when logging in through pt.wikis would be a
huge improvement, and we'd be very glad if that could be implemented :)

(In reply to comment #52)
By the way, I take the opportunity to encourage the implementation of the
workaround for br.wikimedia mentioned by reedy in Comment 44.

https://gerrit.wikimedia.org/r/#/c/47315/

Tested as working:
<img src="//br.wikimedia.org/wiki/Special:AutoLogin?token=REMOVED" alt="br.wikimedia.org" title="br.wikimedia.org" width="20" height="20" style="border: 1px solid #ccc;">(In reply to comment #53)

What else needs doing to fix close this bug? What other projects need exceptions adding for them?

MZMcBride added a comment.Via ConduitFeb 3 2013, 2:18 AM

(In reply to comment #56)

https://gerrit.wikimedia.org/r/#/c/47315/

Tested as working:
<img src="//br.wikimedia.org/wiki/Special:AutoLogin?token=REMOVED"
alt="br.wikimedia.org" title="br.wikimedia.org" width="20" height="20"
style="border: 1px solid #ccc;">(In reply to comment #53)

What else needs doing to fix close this bug? What other projects need
exceptions adding for them?

Hrmmmm. I'm not sure this is a sensible approach. I'm concerned that with this system, we'll just see more and more bugs (related to user confusion) and administrative overhead (for specific exemptions). This system doesn't seem scalable or sustainable.

I think this problem is being approached in the wrong way. Isn't the "load image to log in" feature just a hack? I seem to remember some better system for doing this. One that would allow for an array of allowed wikis to be passed properly to the browser. What happened to that?

Solstag added a comment.Via ConduitFeb 5 2013, 1:04 PM

@Sam

Thank you!

This is a really nice improvement both for editors wanting to engage in activities and also to make our work during wiki workshops less clunky. =D

I think this fixes my original bug (Bug 23151), though the present bug seems a bit more general. I do tend to agree with MZM that this deserves a more stable and universal solution...

Cheers, and again thanks!

ale (User:Solstag)

bzimport added a comment.Via ConduitFeb 5 2013, 1:41 PM

everton137 wrote:

Thank you for all the efforts put to solve this! This is really good news. Tom

Reedy added a comment.Via ConduitFeb 28 2013, 1:00 AM

Marking as fixed.

If any other communities want extras/exceptions, they can open a new bug to request it.

He7d3r added a comment.Via ConduitJul 14 2013, 6:33 PM

See also:

  • SUL (Single User Login) deploy to all wikis on Thursday July 11th

http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-July/000291.html

MarcoAurelio moved this task to Done on the MediaWiki-extensions-CentralAuth workboard.Via WebMay 5 2015, 6:11 PM

Add Comment