Last modified: 2013-07-14 18:33:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14407 - CentralAuth global session doesn't include some *.wikimedia.org public wikis
CentralAuth global session doesn't include some *.wikimedia.org public wikis
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Low normal with 17 votes (vote)
: ---
Assigned To: Sam Reed (reedy)
: shell
: 14509 20251 24471 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-04 15:53 UTC by Andrew Leung
Modified: 2013-07-14 18:33 UTC (History)
33 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Andrew Leung 2008-06-04 15:53:12 UTC
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)?
Comment 1 Tim Starling 2008-06-07 01:37:20 UTC
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. 
Comment 2 Andrew Leung 2008-06-07 02:23:11 UTC
(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. 
Comment 3 Brion Vibber 2008-06-11 21:03:18 UTC
*** Bug 14509 has been marked as a duplicate of this bug. ***
Comment 4 Melancholie 2008-06-11 21:20:33 UTC
Maybe add a checkbox at [[Special:UserLogin]] for optionally logging in on all Wikimedia wikis.
Comment 5 brianna.laugher 2008-07-06 09:48:41 UTC
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.
Comment 6 Casey Brown 2008-07-06 19:14:57 UTC
(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).
Comment 7 Daniel U. Thibault 2008-07-11 01:14:36 UTC
Add me to the list of those that would like to have at least the option of including Wikispecies to the SUL.
Comment 8 Siebrand Mazeland 2008-08-16 23:01:26 UTC
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.
Comment 9 Andrew Leung 2008-08-16 23:40:41 UTC
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? 
Comment 10 Daniel U. Thibault 2008-08-17 23:40:32 UTC
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.
Comment 11 Platonides 2008-08-18 10:56:36 UTC
> 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?
Comment 12 Jelle Zijlstra 2008-08-18 12:00:37 UTC
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.
Comment 13 Siebrand Mazeland 2008-08-18 12:12:41 UTC
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?
Comment 14 suicidal.hamster 2008-08-18 15:13:10 UTC
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).
Comment 15 EVula 2008-08-18 21:46:33 UTC
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.
Comment 16 J JIH 2008-09-14 02:54:37 UTC
Recently, multilingual Wikisource wikisource.org seems to be disconnected from the global log-in.
Comment 17 Ting Chen 2008-11-12 06:08:53 UTC
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.
Comment 18 Mike.lifeguard 2008-11-16 18:32:45 UTC
(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.
Comment 19 EVula 2008-11-17 20:22:36 UTC
(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.
Comment 20 Brion Vibber 2008-12-01 23:56:54 UTC
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...)
Comment 21 Mike.lifeguard 2009-06-27 22:43:13 UTC
(In reply to comment #20)
> Added species to the session setup list per request.
> 

Changed summary accordingly.
Comment 22 Le Chat 2009-09-26 15:33:21 UTC
Are meta and Mediawiki supposed to be included? I never seem to be logged in when I go there.
Comment 23 Andrew Leung 2009-09-27 02:08:54 UTC
Meta's definitely included. Not sure about Mediawiki though.
Comment 24 Le Chat 2009-09-28 13:06:32 UTC
Meta doesn't work for me. Should I report that as a separate bug?
Comment 25 Betacommand 2010-05-10 15:21:45 UTC
Changed title to reflect actual comments and am closing bug as it appears to be fixed
Comment 26 Robin Pepermans (SPQRobin) 2010-05-10 19:51:52 UTC
(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)
Comment 27 Roan Kattouw 2010-05-10 20:30:56 UTC
*** Bug 20251 has been marked as a duplicate of this bug. ***
Comment 28 Roan Kattouw 2010-05-10 20:43:35 UTC
(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
Comment 29 Bryan Tong Minh 2010-07-21 16:52:05 UTC
*** Bug 24471 has been marked as a duplicate of this bug. ***
Comment 30 Sage Ross 2010-07-21 17:02:14 UTC
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.)
Comment 31 M.O.X 2010-10-01 06:54:23 UTC
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.
Comment 32 Brion Vibber 2011-02-17 01:25:58 UTC
*** Bug 24471 has been marked as a duplicate of this bug. ***
Comment 33 Antoine "hashar" Musso (WMF) 2011-05-28 21:30:45 UTC
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 :)
Comment 34 Robin Pepermans (SPQRobin) 2011-05-28 21:39:20 UTC
To be clear, it is OK to add Incubator. I don't know about the rest of the wikis.
Comment 35 Roan Kattouw 2011-06-01 16:23:34 UTC
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.
Comment 36 Robin Pepermans (SPQRobin) 2011-06-23 22:49:37 UTC
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).
Comment 37 Sam Reed (reedy) 2011-08-25 15:14:38 UTC
(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?
Comment 38 Robin Pepermans (SPQRobin) 2011-08-25 19:55:52 UTC
(In reply to comment #37)
> Which are the issues?

How do you mean, issues?
Comment 39 Sam Reed (reedy) 2011-09-28 22:49:57 UTC
I presumably meant what else is outstanding/needs doing?
Comment 40 Robin Pepermans (SPQRobin) 2011-09-29 10:43:57 UTC
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.
Comment 41 Everton Zanella Alvarenga 2012-03-06 11:19:16 UTC
16 people supporting, I have changed to a normal issue, intead of minor. Is that OK?
Comment 42 Al-Scandar Solstag 2012-03-08 09:30:43 UTC
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
.~´
Comment 43 Everton Zanella Alvarenga 2012-03-08 10:07:59 UTC
I second what Solstag said.

Tom
Comment 44 Sam Reed (reedy) 2012-03-12 16:11:14 UTC
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
Comment 45 Platonides 2012-03-15 22:35:49 UTC
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).
Comment 46 Al-Scandar Solstag 2012-03-16 01:17:54 UTC
@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!
Comment 47 Sam Reed (reedy) 2012-03-16 01:47:41 UTC
(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
Comment 48 Krinkle 2012-03-16 04:56:35 UTC
(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.
Comment 49 Al-Scandar Solstag 2012-03-16 05:38:23 UTC
(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
.~´
Comment 50 Platonides 2012-03-16 13:27:48 UTC
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?
Comment 51 Pine 2012-05-30 22:56:59 UTC
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.
Comment 52 Casey Brown 2012-05-30 23:34:29 UTC
(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.
Comment 53 Al-Scandar Solstag 2012-05-31 16:59:48 UTC
(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]]
Comment 54 Sam Reed (reedy) 2013-01-15 15:39:29 UTC
(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.
Comment 55 Sam Reed (reedy) 2013-02-03 01:11:47 UTC
Step 1 https://gerrit.wikimedia.org/r/#/c/47312/
Comment 56 Sam Reed (reedy) 2013-02-03 02:05:40 UTC
(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?
Comment 57 MZMcBride 2013-02-03 02:18:43 UTC
(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?
Comment 58 Al-Scandar Solstag 2013-02-05 13:04:44 UTC
@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)
Comment 59 Everton Zanella Alvarenga 2013-02-05 13:41:00 UTC
Thank you for all the efforts put to solve this! This is really good news. Tom
Comment 60 Sam Reed (reedy) 2013-02-28 01:00:09 UTC
Marking as fixed.

If any other communities want extras/exceptions, they can open a new bug to request it.
Comment 61 Helder 2013-07-14 18:33:36 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links