+1 we’re also doing env per feature
Relaying all that feedback to our product managers!
Aren’t you getting tired of saying that @konrad.sopala? It’s been your response since January 2019.
1 Like
Hey there @jbailey!
Let’s assume following situation. You’re a developer community engineer working at a software product company making its own product. A lot of external devs request certain feature. So you constantly and regularly pass that feedback along with those devs feelings to product managers who are the decision makers. At some point they decide to make this feature available in Enterprise tier.
I’m open for any suggestions from your side what else can I do to be more effective at that and to have that feature for you guys!
1 Like
This thread is a major let down. I’m very wary of using auth0 in a multi-tenant application at this point. In fact, I’m not sure my use-case is even possible.
We plan on having different projects hosted on our service, each with a vanity subdomain. foo.example.com, bar.example.com, etc. End-users may visit multiple projects so I’d like to not have to require sign in multiple times. The number of projects probably won’t be too many, but could definitely approach mid 4-digits.
Option 1 would be to use the management API to add callback urls to my Application for each project. That’s a hassle compared to the desired wildcard urls… but not terrible either. That’s way over this 100 url “soft limit” though. It would help to have some clarity on what the hard limit is, if any. This obviously isn’t something I can just hope isn’t a problem later on.
Option 2 would be to create multiple Applications to represent each project. Here I also worry about running into unpublished limits since I’d be creating potentially thousands of these. Even more problematic, if users browse from foo → bar they will be requesting credentials using a different client id and (presumably?) have to sign in again.
To all the Netlify users that are going through the same turmoil as some described above, I’m pleased to tell you that I’ve coded a build plugin that you can use to overcome this situation.
https://github.com/netlify/build/issues/655#issuecomment-622365876
2 Likes
Thank you for sharing that with the rest of community @romain.bessuges!
1 Like
Not trying to spam, but would like to throw our hat in the ring here as well. We have a product that is built on a subdomain-per-team (like Slack). Right now we’re under the 100 limit (if this is really a thing) but hope to exceed that at some point soon. Not sure what we’ll do then.
Thanks for continuing to respond. I understand the position you’re in…hopefully if enough of us continue to lean on this issue it will help get some traction.
Oops missed this one. The use case is similar to a lot of others here. CI deployments etc
Azure released Static Sites with automatic deployments on Github PR builds today:
This is incredibly useful but I’m unable to continue using it due to having no way to whitelist https://*.eastus2.azurestaticapps.net etc. I hope this is resolved sometime soon.
Hi folks - i’m another one in a situation where I have a multitenant application where each customer gets their own URL. Each tenant needs their own subdomain because of how the app is architected internally, and mirroring our tenant list in the Auth0 configuration via the API just isn’t feasible or maintainable (especially since it doesn’t seem the limits of that field are documented anywhere).
To help your product managers understand the design here, each tenant in our system receives their own server container with an entirely separate instance of the product. We don’t want to centralize auth at one URL because each tenant has the flexibility to run different versions of the application, and the authentication logic should be updated along with the rest of the app to avoid breaking changes impacting tenants in an unpredictable way.
I’d like to understand nicolas_sabena’s post more in depth about what the risks are that Auth0 is trying to mitigate by disallowing wildcards in this scenario. We completely control our domain, so anyone who can redirect one of our subdomains can just as easily redirect our root domain. I can easily understand the risks for someone blanket authorizing an entire cloud provider domain they don’t control, like *.azurewebapps.net, but for us, the subdomains and root domains are exactly equivalent in control and authoritativeness. And skimming that RFC, I don’t see anything specifically mentioning wildcards - lots of discussion about validating the original URL is intended, but nothing that says that securely defining a range of acceptable URLs to be validated against is a risk at first glance.
Could there perhaps be a compromise that allows Auth0 to verify a TXT record in a domain to prove control before allowing it to be whitelisted?
I’ve gotten 95% of the way to launch because wildcards work fine in the other fields, and it’s only now that we’ve been doing more significant testing in prod with multiple tenants that requires refreshing that we’re realizing this limitation exists. We’re pretty much screwed and are trying to figure out whether we have to rip out Auth0 entirely at the last minute and replace with a different auth solution at this point.
Any mitigations or advice you can offer would be greatly appreciated.
2 Likes
Whether or not this gets fixed in the product, at a bare minimum this limitation should be documented on Subdomain URL Placeholders - the difference between Allowed Web Origins and Allowed Origins (CORS) isn’t immediately clear in the UI, and this document completely glosses over the wildcard limitation for Allowed Web Origins. That document is what I reviewed before deciding to architect my product using subdomains for each tenant…
1 Like
Just wanted to up this as a feature behind a big warning that says “This is dangerous”. We could really use this for a staging environment.
Hello Everyone! Thanks for all the great input and sharing your use-cases. We clearly have some room to improve in our docs and our explanations regarding this capability, in addition to solving for the CI/CD scenarios described above.
With that, we are actively looking into improving this experience and solving for these scenarios. I don’t have any timelines that I can share now, but we will follow up in this thread once we have clearer timelines and solutions.
Thanks!
2 Likes
I put in a ticket and was told we all needed to submit our feedback to make them prioritize this. Apparently the forum is not enough of a voice.
Auth0: Secure access for everyone. But not just anyone. is the URL.
Apologies but this system, wont let me tage everyone to one post so going to have to do it in several…
@akdewolfe @shared_auth0 @boyish @ari.frankel @ahumblenerd @akernander @bramski1 @todda00
1 Like