RFC: Alternative domains for Commons

List overview All Threads
Download

newer

older

Fwd: [Wikimedia-GH] Wikipedia...

Bugzilla Weekly Report

Juliusz Gonera

21 Mar 2013 21 Mar '13

3:20 p.m.

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/ -- Juliusz

Show replies by date

Arthur Richards

22 Mar 22 Mar

8:09 p.m.

+ops On Thu, Mar 21, 2013 at 8:20 AM, Juliusz Gonera <jgonera(a)wikimedia.org>wrote;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/<http:… [2] https://developer.mozilla.org/**en-US/docs/Site_Compatibility_** for_Firefox_22<https://developer.mozilla.org/en-US/docs/Site_Compatibili… [3] https://gerrit.wikimedia.org/**r/#/c/54813/<https://gerrit.wikimedia.org… -- Juliusz ______________________________**_________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…

-- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

MZMcBride

8:22 p.m.

Juliusz Gonera wrote:

...

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

Brian Wolff

8:25 p.m.

On 2013-03-22 5:22 PM, "MZMcBride" <z(a)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

...

[3] https://gerrit.wikimedia.org/r/#/c/54813/

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

Brion Vibber

8:27 p.m.

On Fri, Mar 22, 2013 at 1:22 PM, MZMcBride <z(a)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

Juliusz Gonera

27 Mar 27 Mar

9:07 p.m.

On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride <z(a)mzmcbride.com> wrote:

...

Please draft an RFC at <https://www.mediawiki.org/wiki/RFC>. :-)

http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Doma… 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

...

Petr Bena

28 Mar 28 Mar

7:41 a.m.

...

On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride <z(a)mzmcbride.com> wrote:

Please draft an RFC at <https://www.mediawiki.org/wiki/RFC>. :-)

http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Doma… 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

K. Peachey

7:44 a.m.

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(a)gmail.com> wrote:

...

On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride <z(a)mzmcbride.com> wrote:

Please draft an RFC at <https://www.mediawiki.org/wiki/RFC>. :-)

http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Doma… 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Petr Bena

7:47 a.m.

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(a)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(a)gmail.com> wrote:

On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride <z(a)mzmcbride.com> wrote:

Please draft an RFC at <https://www.mediawiki.org/wiki/RFC>. :-)

http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Doma… 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Petr Bena

7:45 a.m.

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(a)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(a)wikimedia.org> wrote: > On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride <z(a)mzmcbride.com> wrote: > >> Please draft an RFC at <https://www.mediawiki.org/wiki/RFC>. :-) >> > > http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Doma… > 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(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Juliusz Gonera

11:44 p.m.

On Thu, Mar 28, 2013 at 8:45 AM, Petr Bena <benapetr(a)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). -- Juliusz

Seb35

8:59 a.m.

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(a)gmail.com> a écrit:

...

On Fri, Mar 22, 2013 at 9:22 PM, MZMcBride <z(a)mzmcbride.com> wrote:

Please draft an RFC at <https://www.mediawiki.org/wiki/RFC>. :-)

http://www.mediawiki.org/wiki/Requests_for_comment/Alternative_Commons_Doma… 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Juliusz Gonera

11:45 p.m.

On Thu, Mar 28, 2013 at 9:59 AM, Seb35 <seb35wikipedia(a)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? -- Juliusz

Seb35

29 Mar 29 Mar

12:17 a.m.

Le Fri, 29 Mar 2013 00:45:03 +0100, Juliusz Gonera <jgonera(a)wikimedia.org> a écrit:

...

On Thu, Mar 28, 2013 at 9:59 AM, Seb35 <seb35wikipedia(a)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.

Daniel Zahn

22 Mar 22 Mar

8:30 p.m.

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_Wikiped… [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]

Juliusz Gonera

27 Mar 27 Mar

8:03 p.m.

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(a)wikimedia.org> wrote:

...

4039

days inactive

4047

days old

wikitech-l@lists.wikimedia.org

Manage subscription

15 comments

9 participants

tags (0)

participants (9)

Arthur Richards
Brian Wolff
Brion Vibber
Daniel Zahn
Juliusz Gonera
K. Peachey
MZMcBride
Petr Bena
Seb35