Last modified: 2013-07-14 18:33:36 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)?
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.
(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.
*** Bug 14509 has been marked as a duplicate of this bug. ***
Maybe add a checkbox at [[Special:UserLogin]] for optionally logging in on all Wikimedia wikis.
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.
(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).
Add me to the list of those that would like to have at least the option of including Wikispecies to the SUL.
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.
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?
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.
> 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?
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.
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?
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).
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.
Recently, multilingual Wikisource wikisource.org seems to be disconnected from the global log-in.
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.
(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.
(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.
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...)
(In reply to comment #20) > Added species to the session setup list per request. > Changed summary accordingly.
Are meta and Mediawiki supposed to be included? I never seem to be logged in when I go there.
Meta's definitely included. Not sure about Mediawiki though.
Meta doesn't work for me. Should I report that as a separate bug?
Changed title to reflect actual comments and am closing bug as it appears to be fixed
(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)
*** Bug 20251 has been marked as a duplicate of this bug. ***
(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
*** Bug 24471 has been marked as a duplicate of this bug. ***
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.)
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.
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 :)
To be clear, it is OK to add Incubator. I don't know about the rest of the wikis.
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.
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).
(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?
(In reply to comment #37) > Which are the issues? How do you mean, issues?
I presumably meant what else is outstanding/needs doing?
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.
16 people supporting, I have changed to a normal issue, intead of minor. Is that OK?
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 .~´
I second what Solstag said. Tom
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
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).
@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!
(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
(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.
(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 .~´
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?
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.
(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.
(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]]
(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.
Step 1 https://gerrit.wikimedia.org/r/#/c/47312/
(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?
(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?
@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)
Thank you for all the efforts put to solve this! This is really good news. Tom
Marking as fixed. If any other communities want extras/exceptions, they can open a new bug to request it.
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
