Last modified: 2010-06-10 00:19:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T22251, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20251 - strategywiki, usabilitywiki, other .wikimedia.org domains not in auto-login list for SUL
strategywiki, usabilitywiki, other .wikimedia.org domains not in auto-login l...
Status: RESOLVED DUPLICATE of bug 14407
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 21766 23151 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-15 04:20 UTC by Liangent
Modified: 2010-06-10 00:19 UTC (History)
6 users (show)

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


Attachments

Description Liangent 2009-08-15 04:20:00 UTC
I always forget to login... and logging in automatically doesn't seem harmful...
Comment 1 Roan Kattouw 2009-08-15 10:04:36 UTC
Logging in on strategy or usability does log me in to Wikipedia and friends, but the inverse doesn't work: logging in on Wikipedia doesn't log me in to strategy and usability, and logging in to usability doesn't even log me in to strategy.

I think this is because *.wikimedia.org domains each have their own image in the post-login screen, and usability and strategy aren't in there.
Comment 2 Tim Starling 2009-08-15 10:09:33 UTC
We could add hundreds of wikis to that list of images to load on login, but I don't think it's a good solution. The login images take too long to load as it is. Perhaps this could be dealt with during a rewrite of CentralAuth.
Comment 3 Roan Kattouw 2009-08-15 10:11:58 UTC
(In reply to comment #2)
> We could add hundreds of wikis to that list of images to load on login, but I
> don't think it's a good solution. The login images take too long to load as it
> is. Perhaps this could be dealt with during a rewrite of CentralAuth.
> 

The difference is that domains like wikipedia.org just have a *.wikipedia.org , while wikimedia.org does not (presumably because there are private wikis on that domain?). Adding these two wikis may not be a good long-term solution, but I'd say it's certainly acceptable as a short-term stopgap so it at least works for now while someone fixes CA to handle this properly.
Comment 4 Tim Starling 2009-08-15 10:23:57 UTC
(In reply to comment #3)
> The difference is that domains like wikipedia.org just have a *.wikipedia.org ,
> while wikimedia.org does not (presumably because there are private wikis on
> that domain?). 

No, it's because that domain has untrusted servers (like amaranth.ts.wikimedia.org, prototype.wikimedia.org and wikitech.wikimedia.org) and untrusted content (like bug-attachment.wikimedia.org) which could compromise the security of the SUL system and give attackers access to users' global accounts.

> Adding these two wikis may not be a good long-term solution, but
> I'd say it's certainly acceptable as a short-term stopgap so it at least works
> for now while someone fixes CA to handle this properly.

If you say so. 
Comment 5 Roan Kattouw 2009-08-18 13:15:53 UTC
This could be fixed by fixing bug 20298
Comment 6 Brion Vibber 2009-08-21 00:49:13 UTC
Correcting summary. They can be added to the explicit autologin list, but I don't really want like 20 rarely-used specialty wikis slowing down every user's logins. The cross-domain cookies are just extra sugar, anyway for now...

Roan, I'm not sure I understand what bug 20298 actually accomplishes. My impression is that it basically would allow the same thing that the <img>-to-set-a-cookie already does, but you could do it by XHR instead of an <img> (only supporting browsers) and it might or might not override users' settings on cross-domain cookie setting.

As I understand, it would still require a hit per site to set the cookies, and wouldn't get past our need to limit access to only certain *.wikimedia.org subdomains.
Comment 7 Liangent 2009-08-22 04:48:40 UTC
we are running a centralnotice pointing to strategywiki. it is bad not to log in automatically.
Comment 8 Roan Kattouw 2009-08-23 10:51:44 UTC
(In reply to comment #6)
> Correcting summary. They can be added to the explicit autologin list, but I
> don't really want like 20 rarely-used specialty wikis slowing down every user's
> logins. The cross-domain cookies are just extra sugar, anyway for now...
> 
There's not that many non-private *.wikimedia.org wikis, only like 7 or so. That'd still double the number of images, of course.

> Roan, I'm not sure I understand what bug 20298 actually accomplishes. My
> impression is that it basically would allow the same thing that the
> <img>-to-set-a-cookie already does, but you could do it by XHR instead of an
> <img> (only supporting browsers) and it might or might not override users'
> settings on cross-domain cookie setting.
> 
> As I understand, it would still require a hit per site to set the cookies, and
> wouldn't get past our need to limit access to only certain *.wikimedia.org
> subdomains.
> 
You're right, I misunderstood what it did. For some reason, undoubtedly influenced by wishful thinking, I was under the impression that it'd allow cookies to go cross-domain (e.g. from *.wikipedia.org to usability.wikimedia.org ) if both domains allowed it. This isn't possible (yet?). Another possible solution using cross-domain AJAX the way it actually works would be to have wikis that aren't on the *.wikipedia.org domain to grab http://en.wikipedia.org/w/api.php?action=query&meta=userinfo , which is passed the user's *.wikipedia.org cookie (because of the Access-Control-Allow-Credentials: true header) and returns whether and as whom the user is logged in at enwiki. There may be some security implications here, so it may be desirable to introduce a new API module for this, but the basic idea sounds like it could work.
Comment 9 Roan Kattouw 2009-12-06 18:42:07 UTC
*** Bug 21766 has been marked as a duplicate of this bug. ***
Comment 10 Roan Kattouw 2010-04-11 10:34:25 UTC
*** Bug 23151 has been marked as a duplicate of this bug. ***
Comment 11 Roan Kattouw 2010-05-10 20:30:56 UTC

*** This bug has been marked as a duplicate of bug 14407 ***

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


Navigation
Links