I have an app that is deployed to Vercel and I need to be able to sign in to apps deployed to the preview env. I have created a project and in the Test environment, I have set a redirect url using the following nomenclature: “https://myapp-*.vercel.app” - however, when I try to sign in to the app I get an error from Stytch that “There are no login redirect URLs registered”
If I use the actual full url for the current preview env, then everything works. I read through the docs at Redirect URLs | Stytch authentication - and it seems I am doing what it says. Any tips our insights would be appreciated!
Hey there,
Thanks for reaching out!
Wildcards should be supported in redirect URLs for Test environments. Could you please share an example request_id? Happy to take a closer look on our end - thank you!
Hi Johanan - thanks for your response. Is that request id something I can send you directly? I’d rather not post any ids or the like here in the forum.
Hi Anders,
I don’t believe the request_id should result in any sensitive information exposed, but definitely understand the concern there.
Please feel free to send it (and any other relevant info) via support@stytch.com.
Thanks,
Hey Anders,
Thanks for sending that over!
Looking at the logs on our end, it looks like you’re including the wildcard in the redirect URL parameter for the API call itself.
While we allow using wildcards when setting allowed redirect URLs in the Stytch Dashboard (in our Test environment), during the authentication flow itself a valid (non-wildcard) redirect URL needs to be supplied; e.g.https://myapp-1234.vercel.app rather than https://myapp-*.vercel.app.
This is because Stytch will redirect to the URL supplied in the API call, so it must be a valid URL. The wildcard allowed redirect URL you set in the Stytch Dashboard means that, for example, both https://myapp-12345.vercel.app and https://myapp-678910.vercel.app can be passed into a given authentication flow, and either will be validated successfully.
I hope this helps; happy to help with any further questions you might have!
Hi Matthew - thanks for getting back to me. Not sure what you mean by including a wildcard in the API call. This is how I am calling the API on my login page:
(in a separate file)
export const stytchClient = new stytch.Client({
project_id: ENV.STYTCH_PROJECT_ID,
secret: ENV.STYTCH_SECRET,
});
(then on POST on the login page)
const res = await stytchClient.magicLinks.email.loginOrCreate({
email,
});
The only place I have used a wildcard is in the redirect URL config in the stytch dashboard.
Please let me know if I can provide more details regarding my implementation if that helps.
Actually, could you maybe show me what you’re seeing that is indicating that I am using a wildcard somewhere? That could help me debug. Thanks again.
Hey Anders, sorry for the confusion here!
It actually looks like you were able to set a default redirect URL with a wildcard in it, which should be disallowed, but wasn’t for some reason. I’ve flagged that issue for our engineering team.
Because you set your URL with a wildcard as the default, we’re attempting to use it when you don’t specify login_magic_link_url and signup_magic_link_url values in your magicLinks.email.loginOrCreate requests (because we fall back to the default redirect URL when those values aren’t provided). We’re then erroring the requests because we can’t redirect to a URL with a wildcard in it, since we don’t know the actual full destination.
In order to resolve this, I’d recommend:
- Setting your default redirect URL to a URL without a wildcard in it. You can still keep your original redirect URL (with the wildcard) in your redirect URL allowlist, just not as the default.
- Specifying the full redirect URL that users should be redirected to in your
magicLinks.email.loginOrCreate requests via the login_magic_link_url and signup_magic_link_url values.
I hope that makes sense! Happy to help with any additional questions you have about this.
Thanks for the additional info. I tried doing what you suggested. I set the default redirect URL as the prod url, which is the only stable redirect url and then added a wildcard URL. However, that resulted in that I was ultimately redirected to the /authenticate url for prod, which obviously is not what I want.
The only thing that worked was to get the current domain host and then explicitly set both the login_magic_link_url and signup_magic_link_url
I don’t recall seeing anything about taking that approach in the docs, so here is my code for doing that:
// util for getting the current host
export function getDomainHost({
request,
withProtocol,
}: {
request: Request;
withProtocol?: boolean;
}) {
const host =
request.headers.get(“X-Forwarded-Host”) ??
request.headers.get(“host”) ??
new URL(request.url).host;
if (withProtocol) {
return ${host.includes("localhost") ? "http" : "https"}://${host};
}
return host;
}
// in the login POST
const redirectUrl = ${getDomainHost({ request, withProtocol: true })}/authenticate;
const res = await stytchClient.magicLinks.email.loginOrCreate({
email,
login_magic_link_url: redirectUrl,
signup_magic_link_url: redirectUrl,
});
Hey Anders! Awesome – that’s the strategy that we’d recommend. When you need to set a redirect URL that isn’t your default redirect URL (which in your case is your production URL), then setting the login_magic_link_url and signup_magic_link_url values directly in your request as you’re now doing is the right way to go about it.
Please let us know if any additional questions about this come up!
Oh, and as an added security measure, I am only setting these redirects in the preview envs:
const isPreviewEnv = process.env.VERCEL_ENV === “preview”;
const redirectUrl = isPreviewEnv
? ${getDomainHost({ request, withProtocol: true })}/authenticate
: undefined;
const res = await stytchClient.magicLinks.email.loginOrCreate({
email,
login_magic_link_url: redirectUrl,
signup_magic_link_url: redirectUrl,
});
One thing I’m not clear on is what the default URL should be when using Vercel preview URLs? Is there a working example of a node app with all the correct config that one could look at?
Hi there,
For this use case, you can use anything for the default redirect URL, such as a stable domain of any kind for your app.
Since you’d always want to pass in values for login_magic_link_url and signup_magic_link_url and set those to the current domain of your Vercel app’s preview environment, it should use that instead of falling back to the default redirect URL.
Just to be clear, what I did was a workaround, since there does not seem to be an actual documented solution for redirecting to preview URLs, or the current documentation seems to be inaccurate or incomplete.
Thanks for your reply!
Default redirect URLs don’t (or at least aren’t supposed to) support wildcards today, so for your use case of preview URLs, I believe the intended approach is to pass in login_magic_link_url and signup_magic_link_url as you’re doing currently.
Definitely agree that this could be better documented - at the moment you can find some more details on the approach for setting these here:
and an example here (albeit not specifically centered around test/preview envs):
That being said, we’ll forward this feedback to the team and look to clarify this in our documentation, but in the interim please let us know if you have any additional questions!