On Tue, Mar 19, 2013 at 11:21 AM, Jon Robson <jdlrob...@gmail.com> wrote: > Chris: On the latest iPhone cookies were not accepted from iframes > from sites that were not visited. You had to physically visit the site > by following a link or typing the url into the address bar first. We > are currently investigating whether meta refresh etc can help here - > although that's not ideal. For our projects that would result in over > 13 redirects - a horrible user experience!! > > Correct me if I'm wrong but the 2 problems that CentralAuth solves are > 1) Takes away the inconvenience of having to login across multiple sites > 2) Allows communication between wiki sites via CORS that require > authentication.
#2 is a more recent addition, which we're using in mobile for photo uploads, but it wasn't an original target. #1 has two components: A) can use the same username & password to log in everywhere B) only log in once, and have it apply on our other sites A) is achieved with a central database for user credentials B) is achieved within domains (*.wikipedia.org) by setting a cookie that works across subdomains (still safe) B) is achieved *across* domains by using special trigger images to set third-party cookies (now endangered) > I'm guessing openid / oauth will solve #1 ? Not really, we'd probably want to keep using the same backend central user database for CentralAuth. > An idea I've banded around to solve #2 would be to allow wikis to > access other projects via the api. > > e.g. > http://en.wikipedia.org/w/api.php?action=query&titles=Photo&project=commons > would allow a developer to access the page Photos on > wikimedia.commons.org rather than having to resort to a CORS request > (ie. it would route the query to the database for commons rather than > wikipedia) > > For api requests that require credentials it would send the > credentials of the current project (in this case wikipedia). > > Is that something that is feasible? I did some experimentation a couple weeks ago with this, using a sort of HTTP proxy mode that passed through the CentralAuth session token cookies. This turned out to be a dead-end because we needed edit tokens for the foreign site, and we weren't getting a consistent *local* session on the other side of the proxy between requests. This could perhaps be solved in a few ways: * store the session edit token in the global CentralAuth session instead of the per-wiki session * use session state on the proxying wiki to store proxied-wiki's local session cookies * direct DB access to the other sites (possibly something could be rigged up that takes over the proxy before MediaWiki configures, and switches configurations to match the target site?) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
