Page MenuHomePhabricator

Use CORS for cross domain login
Closed, DeclinedPublic

Description

See the example in the URL. Implementing this would make it work for Safari and other browsers that have strict origin restrictions on cookies.


Version: unspecified
Severity: enhancement
URL: https://developer.mozilla.org/En/HTTP_access_control#Requests_with_credentials
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=28700

Details

Reference
bz20298

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:53 PM
bzimport set Reference to bz20298.
bzimport added a subscriber: Unknown Object (MLST).

Bug 20251 could also be fixed by implementing this.

The term "CORS" doesn't appear on the referenced page; can you maybe clarify? :)

(In reply to comment #2)

The term "CORS" doesn't appear on the referenced page; can you maybe clarify?
:)

See also r54127

Created attachment 7607
patch for cross domain central auth

I have no testing environment for this, but I suppose this patch could do the trick.

attachment xsscentralauth.patch ignored as obsolete

We could also use wgCentralAuthAutoLoginWikis of course instead of wgCentralAuthCrossSiteDomains.. Not really sure on that one...

Created attachment 7608
patch for cross domain central auth v2

Corrected syntax error in the patch.

Attached:

For me Internet Explorer 8 does not work properly, other users reported problems with Opera:

You are not logged in despite checking "globally login"-box when logging in de.wikipedia.org and then going to commons.wikimedia.org. But on en.wikipedia.org you are logged-in.

It is just confusing for the user if it is said "login sucessful" but it is actually not.

(In reply to comment #9)

For me Internet Explorer 8 does not work properly, other users reported
problems with Opera:

You are not logged in despite checking "globally login"-box when logging in
de.wikipedia.org and then going to commons.wikimedia.org. But on
en.wikipedia.org you are logged-in.

It is just confusing for the user if it is said "login sucessful" but it is
actually not.

Is this a problem with this patch, or a problem you're experiencing on the live site right now? If the latter, you're commenting on the wrong bug.

(In reply to comment #10)

Is this a problem with this patch, or a problem you're experiencing on the live
site right now? If the latter, you're commenting on the wrong bug.

Never mind, I didn't read comment #0 properly. Strict origin restrictions on cookies break the auto login feature.

(In reply to comment #5)

Created attachment 7607 [details]
patch for cross domain central auth

I have no testing environment for this, but I suppose this patch could do the
trick.

Looks good to me. We have a similar CORS implementation in the API that suffers from caching issues, but since Special:Autologin isn't cached we should be good here.

attachment xsscentralauth.patch ignored as obsolete

What shall we do with this one then ? I had all but forgotten about it. I guess we might want to reuse some of the concepts added to the CORS Api implementation now. at least in terms of syntax for the config option ?

I think this is no longer useful. cookie accept rules have been so far tweaked now, that not even withCredentials will let you bypass. if you have don't accept from 3rd parties enabled (or safari's don't accept from unknown 3rd parties), the cookie information is simply ignored by the browsers.

On safari, when you have visited before, it works, but it works just as well with the cookies of the images, so no added benefit.

I'm closing this wontfix.

bug 46901 and specifically sul2 are now the focus to address the problem that this solution was attempting to solve.

MarcoAurelio raised the priority of this task from Medium to High.May 5 2015, 6:14 PM
MarcoAurelio moved this task from Incoming to Done on the MediaWiki-extensions-CentralAuth board.