Description
Related Objects
Event Timeline
@Kenrick95, the fix for T62835 should address this issue sufficiently, without the need to explicitly add "localhost" to $wgCrossSiteAJAXdomains. Do you have other information that leads you to believe that localhost needs to be explicitly listed?
Since that task has no new comment since Nov 2015, I think it's better to allow "localhost" first before extending it to that task itself, i.e. solve smaller issue before solving a much larger issue.
Honestly, I feel a bit iffy about this. I'm not sure if there would be any security badness from doing this, but it just feels "icky"
Maybe people who need this sort of thing, could just add something like
foo.wikipedia.org 127.0.0.1
To their /etc/hosts, and then test their thing using foo.wikipedia.org as the local web server.
@Bawolff Not sure a DNS kludge is optimal. You can't change /etc/hosts on Chromebooks (ChromeOS mount this partition in read only mode) or on machines you are not root. But then, develop on a machine without root access isn't optimal, and we have recommendations for Vagrant.
@csteipp Do you see any risk (a rogue browser extension for example?) for a CORS rule including localhost?
If you arent root you cant run a webserver on port 80 or 443, so this bug wouldnt help you.
I think T62835: Enable cross-domain API requests in API's JSON responses will address the main use cases, and adding localhost does not seem like a wise thing to do. While I sympathize with making things easier for developers, I think this opens too much attack surface for the benefit.