Has anyone else used Ory with the nextjs-app-router on Vercel? I am experiencing this issue where the login flow redirects me to a commit-specific Vercel URL when I kick off the auth flow. (Continuing from https://ory-community.slack.com/archives/C02MR4DEEGH/p1744216655875899)

Is this for use in production? In production you typically don't need the middleware, because Ory's URL would be on the same domain (can still be a different subdomain). So Cookies & CORS are not an issue, as they are in development/preview envs.

@bland-eye-99092 no, not for production.

URL would be on the same domain (can still be a different subdomain). So Cookies & CORS are not an issue

Isn’t a different subdomain still a separate origin?

Yes, but you can configure both CORS and especially Cookies easily to work on both - if they are on the same second-level domain. With the removal of third party cookies, we disallow issuing cookies on different second level domains - hence the distinction. And the middleware makes working with local deployments much easier, than having to deal with CORS on those local envs. Am I understanding correctly, that you have a preview deployment with a custom domain?

Right, we have https://beta.source.coop/. However, if you begin that login flow in the upper right hand corner, we get redirected to the the semi-random deployment URL

do you have a custom domain set up? If you have a custom domain, the CORS issue goes away, AFAIK.

I can take another crack at that but I believe I went down that road…

We're in the process of streamlining all of that. But if you're on nextjs, you won't need the tunnel anymore, as the middleware handles all of that. We're not quite there yet, though. So the edges are still pretty rough. We really appreciate your rigorous feedback though! As for the original issue: we recommend using CNAMEs for production and production like envs. However, you could be running into this: https://github.com/ory/elements/blob/83015ee711a0c93685f7db89aebcb773482729b8/packages/nextjs/src/utils/sdk.ts#L36-L50, It would be interesting to know what the value of

VERCEL_ENV

is for your deployment.

Your link isn’t working, but I assume you’re referencing the code I mentioned here: https://ory-community.slack.com/archives/C02MR4DEEGH/p1745252111240049?thread_ts=1745251949.679419&cid=C02MR4DEEGH

do you have time / interest in a quick pair call?

Ah yea, you already linked that - sorry. I'll have to read through the linked issue to get a better understanding, but it looks like we might need to add special handling for

VERCEL_ENV=preview

, as that should behave similar to

production

, IMO. Your end goal is to move the hosted account experience?

Your end goal is to move the hosted account experience?

I think that would be the best, we don’t have super strict branding needs that couldn’t be addressed with Ory hosted. We actually do use the Ory hosted setup in production today (https://auth.source.coop/) but have basically rewritten the frontend and I’m trying to understand what is necessary from the legacy-style of using Ory to the modern-style of using Ory. ie, I’m loving the middleware rather than the tunnel, but I’m not sure what the ideal auth flow is for a NextJS app with SSR. Some Ory docs reference cookies, others reference the classic Client Authorization flow which I assumes implies JWTs. I’m having some issues understanding which auth workflow would be ideal for a modern NextJS app that would fit in with Ory’s best-practices in the upcoming future

We're still looking into how to solve this. You can follow along here: https://github.com/ory/elements/pull/484 We most often recommend Cookie based auth, because of the drawbacks (complexity, handling tokens, etc.) of oauth2. If you don't have a specific use-case for oauth2, use sessions. Ory Elements provides a more hands-on experience, but also greater flexibility than the built-in UIs. You mentioned theming needs that could not be met, what were those?