On Tue, Mar 19, 2013 at 11:21 AM, Jon Robson jdlrobson@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
- Takes away the inconvenience of having to login across multiple sites
- 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=... 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