Hi,
I'm unsure if this is the right place for this question, but I've run into a limitation regarding OAuth client ID setup for local development :
So, when configuring allowed javascript origins for a given client ID, one can either use :
* A valid plublicly-resolvable domain name
* localhost
The ability to use localhost here is great, and very convenient for local development, as long as you only have a single domain.
Traditionally, if you have more than one resource that you want to serve locally simultaneously for development purposes, you'd either :
* put each of them on a different port : this would work, but is quite limited (not obvious which resource is on which port, etc)
* modify the local resolver's configuration (/etc/hosts or equivalent) to make arbitrary fake domains point to localhost (this was typically done with the .dev tld before it became an actual valid tld. This is relatively heavy to configure, error-prone, may lead to edge cases if the domains used aren't registered by the entity, etc)
A better alternative is possible nowadays : localhost subdomains.
As specified by the IETF (https://datatracker.ietf.org/doc/html/rfc6761#section-6.3), any DNS entry ending with `.localhost` should resolve to the loopback address.
Beyond the specification, this _does work_ in practice, at least on sufficiently modern operating systems (tested on Fedora, MacOS, Windows).
This is the best of both worlds, because you don't have any host-level configuration or hack to do, just pick a bunch of localhost subdomains (like, site1.localhost, site2.localhost, etc), and configure your development server to recognize them.
We've been happily using this scheme for a while, it works perfectly.
Now, here comes the issue : it's not possible to declare such subdomains in client ID configuration, hence this feature request.
I do not see any security issue with allowing such domains (no more than allowing localhost itself anyway, and localhost is already currently allowed), but it would represent a significant increase in ease of use for developers.
Could this change please be considered ?
I've got this same issue.
And I agree av-vroomly, how is this a security a risk...? Can it please be updated to allow subdomains?
I'm developing a website that has app (subdomain) and want to test this on localhost e.g. `app.localhost:{port}`