How come "Allowed Web Origins" does not allow wildcards?

Help
1

The other client fields “Allowed Callback URLs”, “Allowed Logout URLs”, and “Allowed Origins (CORS)” all support wildcards…

I want/need wildcard support because I am in the process of moving my Google App Engine application to Auth0’s Hosted Login Page solution and taking advantage of checkSession() in auth0.js to reduce the amout of times the login page is displayed. Everything works great so far.
Google App Engine lets me run multiple versions of my application, with the “default” version being available at my domain address, and other versions are available using appspot.com urls that contain the version (ie. https://1-2-dot-myappid.appspot.com) Since i am constantly adding/testing new versions of my app, i don’t want to have to add each version-specific url to my Auth0 client… for the other client fields, i can add https://*myappid.appspot.com but I cannot do this for “Allowed Web Origins”.
Why?

12 Likes
2

Does google app engine support naming/aliasing envs so you have dev-myapp.appspot.com? I’ve found this: Overview of legacy bundled services  |  App Engine standard environment for Go 1.11 docs  |  Google Cloud. That would be the ideal way to do this. We are changing the support of wildcard to be spec compliant: RFC 6819: OAuth 2.0 Threat Model and Security Considerations

Let me know if that’s possible on Google App Engine.

3

@matias ,

Google app engine recommends separate “projects” for each environment, which does give me dev-myapp.appspot.com, qa-myapp.appspot.com and so on. But i want to run multiple versions of my app inside a single environment. For example, version 1.0.0 in my dev environment would be available at 1-0-0-dot-dev-myapp.appspot.com, and version 1.0.1 would be available at 1-0-1-dot-dev-myapp.appspot.com.

This all works if I add both 1-0-0-dot-dev-myapp.appspot.com and 1-0-1-dot-dev-myapp.appspot.com to the Allowed Web Origins in my Auth0 client… i just don’t want to have to modify my Auth0 client every time I deploy a new version of my app to an environment - i just want to use the wildcard *-dev-myapp.appspot.com like I can do with the other fields in my Auth0 client.

4

We have the same problem with Heroku Review Apps (Review Apps (New) | Heroku Dev Center)

@matias is it possible to configure “Allowed Web Origins” for a client via the Auth0 Management API v2?

1 Like
5

Hi @matias ,

We are developing an app that giving users their own subdomain. Just like you did for your user: https://*.auth0.com/authorize. Is there any workaround to add support for wildcards subdomain?

Thanks!

2 Likes
6

We have the same problem with Heroku Review Apps (Review Apps (New) | Heroku Dev Center)

@matias is it possible to configure “Allowed Web Origins” for a client via the Auth0 Management API v2?

7

Bump this question. I would also like to know the answer

1 Like
9

Same is issue here.What is the work around for this ?

1 Like
10

I"m in the same boat. I have an app that allows custom subdomains. Works for authorize but not checkSession. The only workaround I’ve found so far I actually found by accident because I forgot about checkSession and implemented it myself using auth0.authorize() with prompt: ‘none’ in the config. This worked but rather than using an iframe ends up redirecting the user so you’ll have 2 redirects if the session check fails.

1 Like
11

Thanks for your suggestion @akernander that works quite well. Having wildcard allowed web origins would also fix this problem for my application.

12

We too use multi-tenant custom subdomains for our app, and cannot use checkSession() with silent authentication since wildcard subdomains are not allows for Allowed Web Origins. It would be great if this support was added.

1 Like
13

No problem. It would definitely be helpful if we could just use wildcards in Allowed Web Origins. My work-around works for checking for already logged in on initial load or refreshing the SPA, but I now have to figure out a work-around for refreshing the accessToken in the SPA since we don’t get (and shouldn’t get) the refreshToken. Docs say silent auth is the best way to renew an access token, but in a single page app, it’s a little jarring to have the browser actively redirect the user.

14

Hi, I need this as well.

15

Hi we have this same issue. We have an application where we give users their own subdomains and would definitely like the feature to use wildcard domains as well.

1 Like
16

ZEIT’s Now platform creates immutable deployments like https://my-app-uiyasdf9.now.sh and it’s nice to go to that url and test a deployment before aliasing to a production url.

2 Likes
17

I just tried https://*.now.sh and that worked.

18

not sure what @tim-phillips is talking about, but this still does not work for me.

19

Also having this problem. It’s very annoying because it breaks our entire review process and stops us from being able to take advantage of branch deploy previews from Netlify.

2 Likes
20

Same issue. It would also be nice to allow null as an origin. This would cover file:// protocol scenarios for WKWebview on iOS which enforces CORS even for pages served from file system.

21

I have the same issue. I can’t enter a wildcard in either Allowed Callback URLs or Allowed Web Origins – neither allow a *.

I need it because we are using Platform.sh for development so we have a different subdomain for each branch we test. It’s annoying to have to edit the Application settings in Auth0 for each new branch.

1 Like