Requests for comment/Alternative Commons domains
| Alternative Commons domains | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | Juliusz Gonera |
| Document status | declined Close: superseded, withdrawn by author. -- Tim Starling (talk) 02:15, 16 July 2013 (UTC) |
Background
editWe are introducing a simplified image upload workflow on mobile. This workflow hides the existence of Commons from less experienced Wikipedia users. Basically, it lets them upload images from their phones to Commons using Wikipedia's mobile web site (not knowing and not visiting Commons). We achieve this by using Commons API through AJAX calls (cross-domain AJAX is now possible using CORS). For the Commons API to accept an upload, a person needs to be logged into Commons.
In theory, a person who logs into Wikipedia, should also get logged into Commons. This is achieved using CentralAuth extension which, after you log in to a Wikimedia project, loads images from other projects whose HTTP responses set session cookies on all the other projects' domains. It appears that this is no longer reliable.
Problem
editAs soon as we deployed the first version of image uploads on mobile, we started getting upload errors. Almost all of them came from iPhone/iPad users. We then realized that Safari has a new, stricter cookie policy. Safari (at least the mobile one) will not accept a cookie from a domain which the user has never visited and which doesn't have a cookie set already. So for example, most of Wikipedia users visit wikipedia.org, but have never visited commons.wikimedia.org or even wikimedia.org. Therefore, Safari will not set a cookie for commons.wikimedia.org even though the CentralAuth image from commons.wikimedia.org is loaded on Wikipedia's post-login page. As a result, the user will be logged on Wikipedia, but not on Commons. Mobile Wikipedia will show the image upload feature, but Commons API will reject the upload.
Apart from Safari, Firefox will also start having this policy by default.[1][2]
Proposal
editWe came up with one possible workaround for this problem,[3] which will be deployed in production soon. It is, however, a very hacky workaround and we are afraid that it can stop working anytime. It works as follows:
- When a person visits the Wikipedia login page for the first time, they are redirected to a special page on Commons.
- This special page sets a dummy cookie on commons.wikimedia.org so that Safari (and new Firefox) accept future cookies for this domain, even if the request is made while user is on a different domain.
- As soon as this page is visited, the user gets redirected back to the Wikipedia login page.
- We prevent infinite redirect loop by setting a localStorage value (user is redirected to Commons only the first time they visit login page on their device) and checking HTTP referrer header (if we came from Commons special page, don't redirect back to Commons).
We have another possible idea of avoiding this series of redirects, which, apart from not being very reliable, also influence negatively user experience. If Commons was on the same domain as Wikipedias (commons.wikipedia.org) and accepted API requests on this domain (instead of redirecting to commons.wikimedia.org), the user would be always logged into commons.wikipedia.org (if logged into Wikipedia) because of the cookie set for the *.wikipedia.org domain.
We obviously don't want to move Commons to a new domain for many reasons (most notably, user confusion, SEO, and the fact that Commons is not Wikipedia-specific), so all non-API requests would be still redirected to the canonical address on commons.wikimedia.org.