I always forget to login... and logging in automatically doesn't seem harmful...
Version: unspecified
Severity: normal
Description
Description
Details
Details
- Reference
- bz20251
Event Timeline
Comment Actions
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 Actions
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 Actions
(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 Actions
(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 Actions
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 Actions
we are running a centralnotice pointing to strategywiki. it is bad not to log in automatically.
Comment Actions
(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.