We've been having a hard time making photo uploads work in MobileFrontend because of CentralAuth's third party cookies problem (we upload them from Wikipedia web site to Commons API). Apart from the newest Firefox [1,2], mobile Safari also doesn't accept third party cookies unless the domain has been visited and it already has at least one cookie set.
Even though we have probably found a solution for now, it's a very shaky and not elegant workaround which might stop working any time (if some detail of default browser cookie policy changes again) [3].
I came up with another idea of how this could be solved. The problem we have right now is that Commons is on a completely different domain than Wikipedia, so they can't share the login token cookie. However, we could set up alternative domains for Commons, such as commons.wikipedia.org, and then the cookie could be shared.
The only issue I see with this solution is that we would have to prevent messing up SEO (having multiple URLs pointing to the same resource). This, however, could be avoided by redirecting every non-API request to the main domain (commons.wikimedia.org) and only allowing API requests on alternative domains (which is what we use for photo uploads on mobile).
This obviously doesn't solve the broader problem of CentralAuth's common login being broken, but at least would allow easy communication between Commons and other projects. In my opinion this is the biggest problem right now. Users can probably live without being automatically logged in to other projects, but photo uploads on mobile are just broken when we can't use Commons API.
Please let me know what you think. Are there any other possible drawbacks of this solution that I missed?
[1] http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/ [2] https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22 [3] https://gerrit.wikimedia.org/r/#/c/54813/
+ops
On Thu, Mar 21, 2013 at 8:20 AM, Juliusz Gonera jgonera@wikimedia.orgwrote:
We've been having a hard time making photo uploads work in MobileFrontend because of CentralAuth's third party cookies problem (we upload them from Wikipedia web site to Commons API). Apart from the newest Firefox [1,2], mobile Safari also doesn't accept third party cookies unless the domain has been visited and it already has at least one cookie set.
Even though we have probably found a solution for now, it's a very shaky and not elegant workaround which might stop working any time (if some detail of default browser cookie policy changes again) [3].
I came up with another idea of how this could be solved. The problem we have right now is that Commons is on a completely different domain than Wikipedia, so they can't share the login token cookie. However, we could set up alternative domains for Commons, such as commons.wikipedia.org, and then the cookie could be shared.
The only issue I see with this solution is that we would have to prevent messing up SEO (having multiple URLs pointing to the same resource). This, however, could be avoided by redirecting every non-API request to the main domain (commons.wikimedia.org) and only allowing API requests on alternative domains (which is what we use for photo uploads on mobile).
This obviously doesn't solve the broader problem of CentralAuth's common login being broken, but at least would allow easy communication between Commons and other projects. In my opinion this is the biggest problem right now. Users can probably live without being automatically logged in to other projects, but photo uploads on mobile are just broken when we can't use Commons API.
Please let me know what you think. Are there any other possible drawbacks of this solution that I missed?
[1] http://webpolicy.org/2013/02/**22/the-new-firefox-cookie-**policy/http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/ [2] https://developer.mozilla.org/**en-US/docs/Site_Compatibility_** for_Firefox_22https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22 [3] https://gerrit.wikimedia.org/**r/#/c/54813/https://gerrit.wikimedia.org/r/#/c/54813/
-- Juliusz
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
Juliusz Gonera wrote:
We've been having a hard time making photo uploads work in MobileFrontend because of CentralAuth's third party cookies problem (we upload them from Wikipedia web site to Commons API). Apart from the newest Firefox [1,2], mobile Safari also doesn't accept third party cookies unless the domain has been visited and it already has at least one cookie set.
Even though we have probably found a solution for now, it's a very shaky and not elegant workaround which might stop working any time (if some detail of default browser cookie policy changes again) [3].
I came up with another idea of how this could be solved. The problem we have right now is that Commons is on a completely different domain than Wikipedia, so they can't share the login token cookie. However, we could set up alternative domains for Commons, such as commons.wikipedia.org, and then the cookie could be shared.
The only issue I see with this solution is that we would have to prevent messing up SEO (having multiple URLs pointing to the same resource). This, however, could be avoided by redirecting every non-API request to the main domain (commons.wikimedia.org) and only allowing API requests on alternative domains (which is what we use for photo uploads on mobile).
This obviously doesn't solve the broader problem of CentralAuth's common login being broken, but at least would allow easy communication between Commons and other projects. In my opinion this is the biggest problem right now. Users can probably live without being automatically logged in to other projects, but photo uploads on mobile are just broken when we can't use Commons API.
Please let me know what you think. Are there any other possible drawbacks of this solution that I missed?
[1] http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/ [2] https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22 [3] https://gerrit.wikimedia.org/r/#/c/54813/
Hi Juliusz,
Please draft an RFC at https://www.mediawiki.org/wiki/RFC. :-)
commons.wikipedia.org already redirects to commons.wikimedia.org (for historical reasons, maybe), so that has to be considered. I think what you're proposing is also kind of confusing and I'm wondering if there aren't better ways to approach the problem.
A good RFC will lay out the underlying components in a "Background" section, the problem you're attempting to solve in a "Problem" section, and then offer possible solutions in a "Proposals" section. Variants on this also usually work.
MZMcBride
On 2013-03-22 5:22 PM, "MZMcBride" z@mzmcbride.com wrote:
Juliusz Gonera wrote:
We've been having a hard time making photo uploads work in MobileFrontend because of CentralAuth's third party cookies problem (we upload them from Wikipedia web site to Commons API). Apart from the newest Firefox [1,2], mobile Safari also doesn't accept third party cookies unless the domain has been visited and it already has at least one cookie set.
Even though we have probably found a solution for now, it's a very shaky and not elegant workaround which might stop working any time (if some detail of default browser cookie policy changes again) [3].
I came up with another idea of how this could be solved. The problem we have right now is that Commons is on a completely different domain than Wikipedia, so they can't share the login token cookie. However, we could set up alternative domains for Commons, such as commons.wikipedia.org, and then the cookie could be shared.
The only issue I see with this solution is that we would have to prevent messing up SEO (having multiple URLs pointing to the same resource). This, however, could be avoided by redirecting every non-API request to the main domain (commons.wikimedia.org) and only allowing API requests on alternative domains (which is what we use for photo uploads on mobile).
This obviously doesn't solve the broader problem of CentralAuth's common login being broken, but at least would allow easy communication between Commons and other projects. In my opinion this is the biggest problem right now. Users can probably live without being automatically logged in to other projects, but photo uploads on mobile are just broken when we can't use Commons API.
Please let me know what you think. Are there any other possible drawbacks of this solution that I missed?
[1] http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/ [2]
https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22
Hi Juliusz,
Please draft an RFC at https://www.mediawiki.org/wiki/RFC. :-)
commons.wikipedia.org already redirects to commons.wikimedia.org (for historical reasons, maybe), so that has to be considered. I think what you're proposing is also kind of confusing and I'm wondering if there aren't better ways to approach the problem.
A good RFC will lay out the underlying components in a "Background" section, the problem you're attempting to solve in a "Problem" section, and then offer possible solutions in a "Proposals" section. Variants on this also usually work.
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Imo this sounds like a hacky solution. Also doesnt work for wikis that are not commons.
That said I don't have a better solution atm.
-bawolff
On Fri, Mar 22, 2013 at 1:22 PM, MZMcBride z@mzmcbride.com wrote:
commons.wikipedia.org already redirects to commons.wikimedia.org (for historical reasons, maybe), so that has to be considered. I think what you're proposing is also kind of confusing and I'm wondering if there aren't better ways to approach the problem.
The proposal is to continue to redirect everything *except* API requests, but to allow the API requests to complete and run as though they were requested on commons.wikimedia.org.
This would create a new local session cookie on commons.wikipedia.org based on the *.wikipedia.org CentralAuth session cookie, but this should be harmless (roughly equivalent to logging into Commons on two browsers at once).
Of course, in order to use the same functionality on Wikisource, Wikiversity, Wikivoyage, mediawiki.org etc we'd need similar alternate commons subdomains under those domains.
-- brion
On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride z@mzmcbride.com wrote:
Please draft an RFC at https://www.mediawiki.org/wiki/RFC. :-)
http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Domai... Please share your comments.
commons.wikipedia.org already redirects to commons.wikimedia.org (for historical reasons, maybe), so that has to be considered.
Yes, it redirects. But to solve the problem I'm describing, the API would need to be served from commons.wikipedia.org.
I think what you're proposing is also kind of confusing and I'm wondering if there aren't better ways to approach the problem.
I'm open to suggestions, but I'd rather not wait until CentralAuth gets completely redesigned and rewritten.
What about inserting another domain just to prevent confusion and to keep current redirects, which would ONLY allow api, such as
commons.api.wikipedia.org
the *.api.<project> would just be some kind of universal api gateway for all domains
On Wed, Mar 27, 2013 at 10:07 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride z@mzmcbride.com wrote:
Please draft an RFC at https://www.mediawiki.org/wiki/RFC. :-)
http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Domai... Please share your comments.
commons.wikipedia.org already redirects to commons.wikimedia.org (for historical reasons, maybe), so that has to be considered.
Yes, it redirects. But to solve the problem I'm describing, the API would need to be served from commons.wikipedia.org.
I think what you're proposing is also kind of confusing and I'm wondering if there aren't better ways to approach the problem.
I'm open to suggestions, but I'd rather not wait until CentralAuth gets completely redesigned and rewritten.
-- Juliusz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
How is that meant to pervent confusion? you are just sticking a extra ".api" in the address.
On Thu, Mar 28, 2013 at 5:41 PM, Petr Bena benapetr@gmail.com wrote:
What about inserting another domain just to prevent confusion and to keep current redirects, which would ONLY allow api, such as
commons.api.wikipedia.org
the *.api.<project> would just be some kind of universal api gateway for all domains
On Wed, Mar 27, 2013 at 10:07 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride z@mzmcbride.com wrote:
Please draft an RFC at https://www.mediawiki.org/wiki/RFC. :-)
http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Domai... Please share your comments.
commons.wikipedia.org already redirects to commons.wikimedia.org (for historical reasons, maybe), so that has to be considered.
Yes, it redirects. But to solve the problem I'm describing, the API would need to be served from commons.wikipedia.org.
I think what you're proposing is also kind of confusing and I'm wondering if there aren't better ways to approach the problem.
I'm open to suggestions, but I'd rather not wait until CentralAuth gets completely redesigned and rewritten.
-- Juliusz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
because right now commons.wikipedia.org is already redirecting to wikimedia
if you change this behavior now, you may confuse some people who were expecting it to redirect... but I don't really care
On Thu, Mar 28, 2013 at 8:44 AM, K. Peachey p858snake@gmail.com wrote:
How is that meant to pervent confusion? you are just sticking a extra ".api" in the address.
On Thu, Mar 28, 2013 at 5:41 PM, Petr Bena benapetr@gmail.com wrote:
What about inserting another domain just to prevent confusion and to keep current redirects, which would ONLY allow api, such as
commons.api.wikipedia.org
the *.api.<project> would just be some kind of universal api gateway for all domains
On Wed, Mar 27, 2013 at 10:07 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride z@mzmcbride.com wrote:
Please draft an RFC at https://www.mediawiki.org/wiki/RFC. :-)
http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Domai... Please share your comments.
commons.wikipedia.org already redirects to commons.wikimedia.org (for historical reasons, maybe), so that has to be considered.
Yes, it redirects. But to solve the problem I'm describing, the API would need to be served from commons.wikipedia.org.
I think what you're proposing is also kind of confusing and I'm wondering if there aren't better ways to approach the problem.
I'm open to suggestions, but I'd rather not wait until CentralAuth gets completely redesigned and rewritten.
-- Juliusz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
or MAYBE, even more evil:
commons.wikimedia.api.wikipedia.org -- where first two domains commons.wikimedia would point to existing domain, that would actually allow you to enable this gateway instantly on all projects for all domains, so that you could use api of fr.wikisource using wikispecies domain:
fr.wikisource.api.wikispecies.org
I don't know if that is actually good for anything :) but it would surely allow you to bypass cookie restrictions everywhere (for api's only). On the other way, I think we could just think of using some different technology than cookies to avoid mess with DNS
On Thu, Mar 28, 2013 at 8:41 AM, Petr Bena benapetr@gmail.com wrote:
What about inserting another domain just to prevent confusion and to keep current redirects, which would ONLY allow api, such as
commons.api.wikipedia.org
the *.api.<project> would just be some kind of universal api gateway for all domains
On Wed, Mar 27, 2013 at 10:07 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride z@mzmcbride.com wrote:
Please draft an RFC at https://www.mediawiki.org/wiki/RFC. :-)
http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Domai... Please share your comments.
commons.wikipedia.org already redirects to commons.wikimedia.org (for historical reasons, maybe), so that has to be considered.
Yes, it redirects. But to solve the problem I'm describing, the API would need to be served from commons.wikipedia.org.
I think what you're proposing is also kind of confusing and I'm wondering if there aren't better ways to approach the problem.
I'm open to suggestions, but I'd rather not wait until CentralAuth gets completely redesigned and rewritten.
-- Juliusz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Mar 28, 2013 at 8:45 AM, Petr Bena benapetr@gmail.com wrote:
I don't know if that is actually good for anything :) but it would surely allow you to bypass cookie restrictions everywhere (for api's only). On the other way, I think we could just think of using some different technology than cookies to avoid mess with DNS
Adding just one domain doesn't seem like a big mess. I'm not sure when we'll have a different technology other than cookies and I'm also afraid that the workaround I described in the RFC won't work forever (if it does work now, we'll know in a few days).
A small issue in this proposition: sub-subdomains are not currently covered by the https certificate.
~s
Le Thu, 28 Mar 2013 08:41:41 +0100, Petr Bena benapetr@gmail.com a écrit:
What about inserting another domain just to prevent confusion and to keep current redirects, which would ONLY allow api, such as
commons.api.wikipedia.org
the *.api.<project> would just be some kind of universal api gateway for all domains
On Wed, Mar 27, 2013 at 10:07 PM, Juliusz Gonera jgonera@wikimedia.org wrote:
On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride z@mzmcbride.com wrote:
Please draft an RFC at https://www.mediawiki.org/wiki/RFC. :-)
http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Domai... Please share your comments.
commons.wikipedia.org already redirects to commons.wikimedia.org (for historical reasons, maybe), so that has to be considered.
Yes, it redirects. But to solve the problem I'm describing, the API would need to be served from commons.wikipedia.org.
I think what you're proposing is also kind of confusing and I'm wondering if there aren't better ways to approach the problem.
I'm open to suggestions, but I'd rather not wait until CentralAuth gets completely redesigned and rewritten.
-- Juliusz
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Mar 28, 2013 at 9:59 AM, Seb35 seb35wikipedia@gmail.com wrote:
A small issue in this proposition: sub-subdomains are not currently covered by the https certificate.
That would make only commons.api.wikipedia.org not work, but not commons.wikipedia.org, right?
Le Fri, 29 Mar 2013 00:45:03 +0100, Juliusz Gonera jgonera@wikimedia.org a écrit:
On Thu, Mar 28, 2013 at 9:59 AM, Seb35 seb35wikipedia@gmail.com wrote:
A small issue in this proposition: sub-subdomains are not currently covered by the https certificate.
That would make only commons.api.wikipedia.org not work, but not commons.wikipedia.org, right?
Yes.
fyi, we have all these:
DNS:
root@sockpuppet:~/pdns-templates# ls -l | grep commons lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.co.uk -> wikimedia.com lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.eu -> wikimedia.com lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.info -> wikimedia.com lrwxrwxrwx 1 root root 13 Jul 19 2012 wikimediacommons.jp.net -> wikimedia.com lrwxrwxrwx 1 root root 13 Jul 19 2012 wikimediacommons.mobi -> wikimedia.com lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.net -> wikimedia.com lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.org -> wikimedia.com
Apache:
/apache-config$ grep commons redirects.conf wikimediacommons.co.uk *.wikimediacommons.co.uk \ wikimediacommons.eu *.wikimediacommons.eu \ wikimediacommons.info *.wikimediacommons.info \ wikimediacommons.jp.net *.wikimediacommons.jp.net \ wikimediacommons.mobi *.wikimediacommons.mobi \ wikimediacommons.net *.wikimediacommons.net \ wikimediacommons.org *.wikimediacommons.org \ wikisource.com *.wikisource.com commons.wikipedia.org \ www.commons.wikipedia.org www.commons.wikimedia.org \ RewriteRule ^/welcometowikipedia$ http://commons.wikimedia.org/wiki/File:Welcome_to_Wikipedia_brochure_EN.pdf [R=301,L] RewriteRule ^/instructorbasics$ http://commons.wikimedia.org/wiki/File:Instructor_Basics_How_to_Use_Wikipedi... [R=301,L] RewriteCond %{HTTP_HOST} (^|.)wikimediacommons.(net|info|mobi|eu|org|jp.net)$ RewriteRule ^(.*)$ http://commons.wikimedia.org$1 [R=301,L,NE] RewriteCond %{HTTP_HOST} (^|.)wikimediacommons.co.uk$ RewriteRule ^(.*)$ http://commons.wikimedia.org$1 [R=301,L] RewriteCond %{HTTP_HOST} =commons.wikipedia.org [OR] RewriteCond %{HTTP_HOST} =www.commons.wikimedia.org RewriteRule ^(.*)$ http://commons.wikimedia.org$1 [R=301,L,NE]
Thanks, but I'm afraid they won't help in solving our cookie problems. We need a subdomain of wikipedia.org (and other projects' domains).
On Fri, Mar 22, 2013 at 9:30 PM, Daniel Zahn dzahn@wikimedia.org wrote:
fyi, we have all these:
DNS:
root@sockpuppet:~/pdns-templates# ls -l | grep commons lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.co.uk -> wikimedia.com lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.eu -> wikimedia.com lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.info -> wikimedia.com lrwxrwxrwx 1 root root 13 Jul 19 2012 wikimediacommons.jp.net -> wikimedia.com lrwxrwxrwx 1 root root 13 Jul 19 2012 wikimediacommons.mobi -> wikimedia.com lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.net -> wikimedia.com lrwxrwxrwx 1 root root 13 Jun 7 2012 wikimediacommons.org -> wikimedia.com
Apache:
/apache-config$ grep commons redirects.conf wikimediacommons.co.uk *.wikimediacommons.co.uk \ wikimediacommons.eu *.wikimediacommons.eu \ wikimediacommons.info *.wikimediacommons.info \ wikimediacommons.jp.net *.wikimediacommons.jp.net \ wikimediacommons.mobi *.wikimediacommons.mobi \ wikimediacommons.net *.wikimediacommons.net \ wikimediacommons.org *.wikimediacommons.org \ wikisource.com *.wikisource.com commons.wikipedia.org \ www.commons.wikipedia.org www.commons.wikimedia.org \ RewriteRule ^/welcometowikipedia$ http://commons.wikimedia.org/wiki/File:Welcome_to_Wikipedia_brochure_EN.pdf [R=301,L] RewriteRule ^/instructorbasics$
http://commons.wikimedia.org/wiki/File:Instructor_Basics_How_to_Use_Wikipedi... [R=301,L] RewriteCond %{HTTP_HOST} (^|.)wikimediacommons.(net|info|mobi|eu|org|jp.net)$ RewriteRule ^(.*)$ http://commons.wikimedia.org$1 [R=301,L,NE] RewriteCond %{HTTP_HOST} (^|.)wikimediacommons.co.uk$ RewriteRule ^(.*)$ http://commons.wikimedia.org$1 [R=301,L] RewriteCond %{HTTP_HOST} =commons.wikipedia.org [OR] RewriteCond %{HTTP_HOST} =www.commons.wikimedia.org RewriteRule ^(.*)$ http://commons.wikimedia.org$1 [R=301,L,NE]
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org