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

Help
68

At the least, the UI needs to warn you that wildcards are invalid in the “origin” field. Thank you!

69

Thank you for providing your opinion on that @jbailey! I just passed it to our product team.

70

Apologies in advance in case my exact use case is already on your radar, I want to give you the opportunity to add my data point.

As mentioned by others, we’re using Netlify deploy previews that generate a subdomain that looks like this: https://deploy-preview-102--<netlify-account>.netlify.com/callback
where <netlify-account> is a placeholder for a unique identifier that’s only tied to our Netlify account and 102 is the identifier of the PR on github.

I would like to add the following wildcard, which should cover all future deploy previews:
https://*<netlify-account>.netlify.com

As far as I understand, this wouldn’t pose a security risk, assuming Netlify makes sure that no other Netlify customers will get a subdomain with our <netlify-account> suffix, which I think is a reasonable assumption to make. I understand that https://*.netlify.com would be a bad idea, perhaps this is a restriction you can build in, or a trigger for a warning or something.

Thanks!

1 Like
71

Thanks for providing that context! I will pass it through to our product team!

72

I would also like to vote for this feature for the same reasons as other people (feature/testing/demo branches)

I have use cases of creating demo branches to demo the tools to different stakeholders.

I do wonder how long/what it takes for the development team to get to a feature since this issue was opened in 2018.

73

Thanks for advocating for this feature @smblee!

I would try to discuss it once again with the engineering and product team what are the roadblocks here and see if there is some public guidance I can reveal.

74

Yes, our team needs this as well

75

Hey there @fh-jashmore!

Can you provide us with your usecase so we can have some justification for our product managers? I believe that going to them and saying them that we have another user who request that feature without any usecase won’t make the whole thing better. Thank you!

1 Like
76

We do face the exact same use case as @edor with Netlify and as the rest of the community are not able to follow your product teams reasoning. Hope to see the issue get fixed soon. It is always sad to see product managers following their own agenda, ignoring their clients needs. I would really like to see PM joining the discussion and not hiding out.

1 Like
77

Let me advocate for that so we can have a joint discussion!

1 Like
78

I’d like to add that since we’re managing our auth0 infra with Terraform it isn’t maintainable/feasible to have an approach like @steve1 (Auth0 Application (Client) generation per dynamic subdomain).

79

Thanks for sharing that!

80

Our last ISO 27001 renewal pointed out that Continuous Deployment is a boon in terms of security. Not having it supported out of the box with Auth0, our authentication system has been noted as an issue or a part at risk in our architecture.

Auth0 can reinforce the spec AND allow wildcard domains. Just put a warning somwhere to say as the current domain matches a wildcard rule it is not secure.

1 Like
81

Thanks for letting us know. I will relay that info the the appropriate team!

82

I received a survey today asking my opinion about my experience Developer Pro. I made sure to mention this issue when responding to the question “What auth0 feature would you most like to see released?”. I encourage others to do the same!

4 Likes
83

Thanks a lot @jbailey for doing that!

84

Like everyone else following this two year old thread, I was hoping that by the time I’d reached the end of it I’d see path forward.

I use zeit now to deploy my app. Like other solutions mentioned it gives me effectively random urls, the follow this sort of pattern http://<project_name>-<random_string>.now.sh, the lack of wildcards is blocking my using Auth0 here.

I’m honestly really disappointed that there’s no movement on adding this feature, it’s clearly requested fairly frequently. Likewise, if it can’t be added, a blog post documenting how to script generating unique, throw away clients would also be useful.

I appreciate Konrad trying to keep us in the loop, it must be very frustrating not being able to say anything other than I’ve passed it on, don’t hold your breath.

3 Likes
85

Same here, using review apps in CI each deployed to random_name.example.com and this makes very hard to sell auth0 anywhere in that sort of setting.

86

Thanks @dek and @ggascoigne for providing that context. I will pass it along to our product managers taking care of that matter!

1 Like
87

I also read this whole thread thinking that since it was started over 2 years and Auth0 being such a prominent tech used in the Zeit/Vercal/Now/Nextjs community that it would have been resolved by the time I got to the bottom of the thread. +1 please address this workflow Auth0 so that we can use our login system on our developer and tennant sub-domain deployments! Is there a public Jira or Trello board your product team has that we can see if the issue is in the pipeline and where in priority it is and ability to +1 it there?