Skip to content
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

Closed
saqbach opened this issue Feb 17, 2021 · 2 comments
Closed

Wildcard Callback URL #295

saqbach opened this issue Feb 17, 2021 · 2 comments
Labels
question Further information is requested

Comments

@saqbach
Copy link

saqbach commented Feb 17, 2021

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 to https://*.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."

  • URL: 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."

  • URL: 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 a AUTH0_COOKIE_DOMAIN set to .domain.com since we noticed the appSession 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 with AUTH0_SESSION_ABSOLUTE_DURATION but I can't seem to get AUTH0_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

@adamjmcgrath adamjmcgrath added the question Further information is requested label Feb 17, 2021
@adamjmcgrath
Copy link
Contributor

Hi @austinhale - thanks for your issue and the congrats :)

We don't support wildcards in BASE_URL, it's used to construct the redirect_uri and post logout redirect uri so it needs to be a full uri.

What's the problem you're trying to solve? I suspect we could make it work with AUTH0_COOKIE_DOMAIN set to .domain.com and dynamically setting the redirect_uri in the login handler, eg.

// 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. "

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?

Correct, the doc you shared states:

The Server part of the SDK can be configured in 2 ways:

1. Environmental Variables
The simplest way to use the SDK is to use the named exports (HandleAuth, HandleLogin, HandleLogout, HandleCallback, HandleProfile, GetSession, GetAccessToken, WithApiAuthRequired and WithPageAuthRequired), eg:
...
2. Create your own instance using InitAuth0
If you don't want to configure the SDK with environment variables or you want more fine grained control over the instance, you can create an instance yourself and use the handlers and helpers from that.
...

@saqbach
Copy link
Author

saqbach commented Feb 18, 2021

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.

@saqbach saqbach closed this as completed Feb 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants