On Tue, Mar 19, 2013 at 11:21 AM, Jon Robson <jdlrobson(a)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…
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