Last modified: 2013-05-18 03:47:03 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 14736 - CentralAuth should gracefully handle browsers rejecting third party cookies
CentralAuth should gracefully handle browsers rejecting third party cookies
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-05 18:14 UTC by MZMcBride
Modified: 2013-05-18 03:47 UTC (History)
7 users (show)

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


Attachments

Description MZMcBride 2008-07-05 18:14:37 UTC
When I log into meta.wikimedia.org, I'm logged into Commons, but I'm not logged in to en.wiki or en.wikt.

When I log into en.wikt, I'm not logged in to en.wiki or other sister projects. But I am logged in at zh.wikt and ast.wikt.

This leads me to believe that the global sessions feature is borked when going across domains. It works for subdomains (en, zh, ast) but not for domains (wiktionary, wikipedia, wikimedia).

Tested on multiple browsers; behavior was consistently broken.
Comment 1 Platonides 2008-07-05 20:38:25 UTC
They are different cookies. One for wikipedias, one for wiktionaries, one for commons, one for meta...
We still don't have One to rule them all, One to find them, One to bring them all, and in the darkness bind them :)

Can you confirm that you have enabled loading images from external domains and that when you log in, the corresponding icon for the project you're then logged out is loaded?
Comment 2 MZMcBride 2008-07-05 20:45:01 UTC
When I log in, it says:

You are now logged in to Wiktionary as "MZMcBride".

Logging you in to Wikimedia's other projects: (where it shows all the other project icons).
Comment 3 Matthew Flaschen 2008-08-10 08:53:38 UTC
Most likely the problem is that your browser is not accepting third-party cookies.  See http://www.opentracker.net/en/articles/all-about-cookies-third-party.jsp
Comment 4 MZMcBride 2008-08-10 21:30:54 UTC
Yes, that does seem to be the issue. So, if there is a way for the software to detect that and either not the load the other icons or at least warn that the login won't be global, that would obviously be preferred.

The current behavior of it telling the user that they are logged in elsewhere when it may or may not be true isn't ideal. And default installations of FF3 (and possibly other browsers) don't allow cross-domain cookies for security reasons.

At a minimum, if the software can't detect and tell the user that they're not logged in globally, a troubleshooting or FAQ link would be nice.
Comment 5 Platonides 2008-08-10 22:06:35 UTC
Updating description.
Comment 6 Platonides 2008-10-04 11:44:29 UTC
What about having Special:Autologin set the cookie and issue a redirect to another Special:Autologin which then shows the logo? (showing a 'bad login' image if it is called without the cookie)
Comment 7 Derk-Jan Hartman 2009-08-18 13:20:53 UTC
This problem would mostly be avoided if bug 20298 is implemented, though a proper error might still be useful of course.
Comment 8 Katherine Ahern 2009-11-29 20:47:36 UTC
I agree with Platonides that it seems to me when we get the images on the other sites, we don’t check whether a login cookie was successfully set. I don't think we need to do any redirects, though.

An idea I had is when we’re getting the images from the other servers (to tell a user he/she is logged in on other sites), we need to check if the cookie is properly set, too:

In SpecialAutoLogin.php on the other sites, when we check this:

$data = $wgMemc->get( $key );

We should also test the cookie:

if($_COOKIE["centralAuthSession"] == $sessionID){ //or however you check for logged-in-ness with the cookie
	$cookieSet = true; 
} else {
	$cookieSet = false;
} 

Then you change this line:

if( !$data ) {

to

if( !$data || !$cookieSet ) {







Comment 9 Platonides 2009-11-29 23:45:07 UTC
(In reply to comment #8)
> I agree with Platonides that it seems to me when we get the images on the other
> sites, we don’t check whether a login cookie was successfully set. I don't
> think we need to do any redirects, though.
> 
> An idea I had is when we’re getting the images from the other servers (to
> tell a user he/she is logged in on other sites), we need to check if the cookie
> is properly set, too:

You can't. The images are not to tell that you are logged in. They are to log you.
The cookie is set when delivering you the image. Thus the need for the intermediate redirect.
Comment 10 Katherine Ahern 2009-11-30 01:10:01 UTC
Ah, gotcha. So the intermediate redirect sets the cookie, then the subsequent page tests and delivers either the image or nothing or a "you aren't necessarily logged in to other wikimedia sites" message?

Sorry if you have to speak sort of slowly to me, I'm new here. Would a redirect cause too much of a load increase?
Comment 11 Platonides 2009-11-30 12:54:18 UTC
> Sorry if you have to speak sort of slowly to me, I'm new here. Would a redirect
> cause too much of a load increase?

It would increase latency. It should be quite cheap in terms of cpu. We could do it
in such a way so the images are served by the squids, instead of the apaches everytime.

Comment 12 Roan Kattouw 2009-11-30 16:30:36 UTC
(In reply to comment #11)
> > Sorry if you have to speak sort of slowly to me, I'm new here. Would a redirect
> > cause too much of a load increase?
> 
> It would increase latency. It should be quite cheap in terms of cpu. We could
> do it
> in such a way so the images are served by the squids, instead of the apaches
> everytime.
> 

No we couldn't, because loading the image sets the cookie generated by PHP. This cookie is unique for each login, so you can't cache it in Squid.

These images are a trick we use so xx.wikipedia.org can set a cookie for *.wiktionary.org: it loads an image from xx.wiktionary.org, and that image sets a cookie. We need to do that on the intermediate page because it needs to happen after the user has logged in, but before they go God-only-knows-where.
Comment 13 Platonides 2009-11-30 16:56:47 UTC
> No we couldn't, because loading the image sets the cookie generated by PHP.
> This cookie is unique for each login, so you can't cache it in Squid.

You would set the cookie when handing the redirect. The redirect would lead 
to a simple script like:
<?php
if (isset($_COOKIE['SUL'])) readfile("loggedin.png");
else readfile("enablecookies.png");

with appropiate headers so squids cache both variants based on cookie existance.
AFAIK they can do that.
It may not provide any benefit, though. I don't think there's any bottleneck on
sending the login images.
Comment 14 Katherine Ahern 2009-12-01 21:58:07 UTC
I was curious about whether using a redirect to set a cookie and then serve an image would work, so I implemented Platonides' suggestion, and it totally does. The redirect page sets the cookie. In FF3.5 third party cookies are disabled by default, so when I visited:

www.networkedtraveler.org/dev/thirdPartyCookies.php

I got the "no cookie set" image. When I changed my browser settings to accept third party cookies I got the other image. Here are the scripts:

www.emergentdatasystems.com/redirect.php

<?php

	//set cookie
	setcookie("testCookie", "set it");

	//redirect
	header("Location: http://www.emergentdatasystems.com/image.php");

?>


www.emergentdatasystems.com/image.php

<?php
if (isset($_COOKIE['testCookie'])) {
	        readfile("images.jpg");
	} else {
		readfile("images-1.jpg");
	}
	
?>
Comment 15 MZMcBride 2013-05-16 05:35:26 UTC
This seems related to bug 46903.
Comment 16 Brad Jorsch 2013-05-17 14:35:42 UTC
(In reply to comment #15)
> This seems related to bug 46903.

Bug 46901 is probably a better link.

Once the SUL2 stuff mentioned there is deployed (I believe the plan is to start testing for deployment in the next week or two), this should be fixed.

FWIW, code to fix bug 46903 is already merged, but not yet deployed or enabled. bug 46904 is another part of it, which is also merged but not yet deployed or enabled. Essential to enabling both of those is bug 46902, which is already completed. And then there's bug 46905, which has code currently in review, which allows user scripts doing CORS requests to work around the third-party cookie issue.
Comment 17 MZMcBride 2013-05-18 03:47:03 UTC
Thank you very much for the info in comment 15 and for cross-referencing those bugs. (It's quite a neat set of bug numbers!)

I'm also very glad to hear this bug may soon be fixed. That's great!

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


Navigation
Links