-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wildcard Callback URL #295
Comments
Hi @austinhale - thanks for your issue and the congrats :) We don't support wildcards in What's the problem you're trying to solve? I suspect we could make it work with // pages/api/auth/[...auth0].js
import { handleAuth, handleLogin } from '@auth0/nextjs-auth0';
export default handleAuth({
async login(req, res) {
// req.host could be 'foo.domain.com' or 'bar.domain.com'
// you can set `BASE_URL` to https://foo.domain.com or https://bar.domain.com
const redirectUri = `https://${req.host}/api/auth/callback`;
try {
await handleLogin(req, res, {
authorizationParams: {
redirect_uri: redirectUri
},
});
} catch (error) {
res.status(error.status || 400).end(error.message);
}
}
}); It's also worth noting from the Auth0 Wildcards for Subdomains doc "Avoid using wildcards for subdomains in production application callbacks and allowed origins as it can make your application vulnerable to attacks. "
Correct, the doc you shared states:
|
Awesomeness. Thanks @adamjmcgrath -- pretty sure if you get @mariano 's PR up on NPM, then we're good to go! Thank you again for your help. We really, really appreciate it. |
Describe the problem
We've upgraded from the beta to 1.0 (congrats!) and are working to get authentication set up for our multi-tenant Nextjs application. We're using the basic setup and have changed our
AUTH0_BASE_URL
tohttps://*.domain.com
however, when attempting to authenticate, we're running into an issue where the*
is being URL encoded and seemingly causing the browser to throw an error.Strangely, the behavior is distinct in Chrome vs Firefox. On Chrome, it fails after submission of credentials on the Universal Login page on the callback: "This site can’t be reached. Check if there is a typo in %2A.domain.com."
https://%2A.domain.com/api/auth/callback?code
On Firefox, it throws an error before it can even connect to the Universal Login: "The page you are trying to view cannot be shown because an error in the data transmission was detected."
https://tenant.auth0.com/authorize?client_id
We added our
https://*.domain.com/api/auth/callback
to the Application Settings Allowed Callback URL's, followed the rules listed on the Auth0 Wildcards for Subdomains doc, and even tried adding aAUTH0_COOKIE_DOMAIN
set to.domain.com
since we noticed theappSession
cookie gets set with the specific subdomain -- nothing seemed to work.We have some ideas on how we might try to hack our way around this, but figured we should ask here first. Are we goofing something up? Is this a bug?
Side question: The documentation doesn't make it super clear, but all of the Optional Config options can be added as environment variables without needing to create our own instance with
initAuth0
right? We can safely use the basic setup + option env variables to get the desired effect? I was under the impression it did since it seemed to work withAUTH0_SESSION_ABSOLUTE_DURATION
but I can't seem to getAUTH0_COOKIE_DOMAIN
to set.domain.com
What was the expected behavior?
Successful authentication :(
Reproduction
Basic setup, but change your 'BASE_URL' to contain a
*
Environment
Version: 1.0.0
OS: Windows 10
Chrome: 88
Firefox 85
The text was updated successfully, but these errors were encountered: