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?

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).

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

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.

Updating description.

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)

This problem would mostly be avoided if bug 20298 is implemented, though a proper error might still be useful of course.

kate wrote:

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 ) {

(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.

kate wrote:

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?

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.

(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.

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.

kate wrote:

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");

}

?>

This seems related to bug 46903.

(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.

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!

Is there anything left to do for this ticket, or should we close it as resolved ?