Services need to share the same domain name
Closed, DuplicatePublic

Description

Unfortunately, there is still a large number of our Zero partners that cannot whitelist us based on the IP address alone. Some of them cannot even have wildcards in the domain names. Thus, we give them a full list of our domains to whitelist. This worked relatively OK for the partners who simply whitelisted a small set of wikipedia languages. Now with the addition of services, that list is about to expand, which means we have to notify each of our partner every time a new subdomain is added. Which also means that chances of something going unnoticed are growing, and people might start being charged unexpectedly.

Possible solutions:

  • proxy, e.g. http://rest.wikimedia.org/... becomes http://service.wikimedia.org/rest/... - which means that Zero extension will have to rewrite all URLs, including dynamic ones in JavaScript (big pain)
  • Drop all non-IP whitelisted partners (Dan, how big is it?)

This is similar to issue in T93808, we need to make sure that all of our services are accessible from the same hostname.

Yurik created this task.Apr 8 2015, 10:05 AM
Yurik updated the task description. (Show Details)
Yurik raised the priority of this task from to Needs Triage.
Yurik added subscribers: Yurik, mobrovac, GWicke and 2 others.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 8 2015, 10:05 AM

RESTBase can easily be set up to proxy requests to back-end services without changing them. Thus, partners would need to whitelist only rest.wikimedia.org. Also, see T95229 for a discussion on putting all API calls as paths under their respective domains.

Yurik set Security to None.
csteipp added a subscriber: csteipp.Apr 9 2015, 5:18 PM

If the services are accessible on a non-authenticated domain like rest.wikimedia.org, that's not ideal, but we can live with it as long as it's factored into the risk analysis of the services going onto that domain. So there should be some sort of process to put new services there, and not just make them accessible by default.

If any service on rest.wikimedia.org needs authentication, then we have a much bigger issue. We either have to be very discriminatory about what services get added, or we have to use a non-cookie method for authenticating.

GWicke added a comment.EditedApr 9 2015, 5:21 PM

We will need to support authenticated requests for private wikis and end points that mutate state (ex: save HTML). The good news is that RESTBase can handle authentication systematically, without necessarily forwarding cookies to backend services.

We are operating under the assumption that the content exposed by RESTBase needs to be just as XSS-secure as anything else we expose on the main wiki domain. Our clients frequently use content in ways that renders domain-based protection ineffective anyway.

Yurik moved this task from Backlog to Graphoid on the Graphs board.Apr 16 2015, 4:03 PM
faidon added a subscriber: faidon.Apr 17 2015, 12:49 PM

There has been previous agreement that non-IP whitelisted partners will be phased out anyway. Domain sniffing won't work on a post-HTTPS world, so this issue is not/won't be services-specific at all.