Bug: guessPotentiallyProxiedOrySdkUrl Returns Wrong SDK Url for Staging (nextJS)

[harleyharl]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.
• I have joined the Ory Community Slack.
• I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

I have run into an issue with the ory/nextjs package, specifically the getLoginFlow function:

elements/packages/nextjs/src/app/login.ts

Line 47 in e159960

export async function getLoginFlow(

We call this function when a user navigates to the login page of our site.

Under the hood it uses this function to determine the ory SDK Url:

elements/packages/elements-react/src/client/config.ts

Line 46 in e159960

export function guessPotentiallyProxiedOrySdkUrl(options?: {

In Vercel we have a production and a staging environment. This works fine for our production environment. But in our staging environment the user is sent to the wrong link, e.g. xyz.vercel.app because the logic in this function causes the us to hit this line which sets our sdk url as the incorrect address:

    if (!isProduction() && process.env.VERCEL_URL) {
      return `https://${process.env.VERCEL_URL}`.replace(/\/$/, "")
    }

But we need the request to be directed to the address we set with this variable, even in staging: NEXT_PUBLIC_ORY_SDK_URL

Always very grateful for your help and continued support 🙏

Reproducing the bug

1. Clone this example project https://github.com/ory/elements/tree/main/examples/nextjs-app-router
2. Publish to Github
3. Link the project in vercel and create a project from main branch.
4. GIve the project an additional custom environment called "staging".
5. Set the environment variable for each environment NEXT_PUBLIC_ORY_SDK_URL as any value.
6. The login flow will work for production environment but fail for staging environment, with users being directed to xyz.vercel.app when they initiate a login sequence

Relevant log output

Relevant configuration

Version

1.0.0-rc.0

On which operating system are you observing this issue?

None

In which environment are you deploying?

None

Additional Context

No response

[ibeckermayer]

I'm running into something similar. Is your production environment at a *.vercel.app domain as well?

[ibeckermayer]

In my case the issue is coming from the function by the same name in the nextjs tree:

elements/packages/nextjs/src/utils/sdk.ts

Lines 28 to 73 in a708dd0

	export function guessPotentiallyProxiedOrySdkUrl(options?: {
	knownProxiedUrl?: string
	}) {
	if (getEnv("VERCEL_ENV")) {
	// We are in vercel
	// The domain name of the generated deployment URL. Example: *.vercel.app
	// This is only available for preview deployments on Vercel.
	if (!isProduction() && getEnv("VERCEL_URL")) {
	return `https://${getEnv("VERCEL_URL")}`.replace(/\/$/, "")
	}
	const productionUrl = getEnv("VERCEL_PROJECT_PRODUCTION_URL") || ""
	if (isProduction() && productionUrl.indexOf("vercel.app") > -1) {
	// This is a production deployment on Vercel without a custom domain, so we use the vercel app domain.
	return `https://${productionUrl}`.replace(/\/$/, "")
	}
	// This is sometimes set by the render server.
	if (process.env["__NEXT_PRIVATE_ORIGIN"]) {
	return process.env["__NEXT_PRIVATE_ORIGIN"].replace(/\/$/, "")
	}
	}
	if (isProduction()) {
	// In production, we use the production custom domain
	return orySdkUrl()
	}
	// Try to use window location
	if (typeof window !== "undefined") {
	return window.location.origin
	}
	if (options?.knownProxiedUrl) {
	return options.knownProxiedUrl
	}
	// We tried everything. Let's use the SDK URL.
	const final = orySdkUrl()
	console.warn(
	`Unable to determine a suitable SDK URL for setting up the Next.js integration of Ory Elements. Will proceed using default Ory SDK URL "${final}". This is likely not what you want for local development and your authentication and login may not work.`,
	)
	return final
	}

It's called in getLoginFlow.

During development (localhost), everything works fine because it hits the return options.knownProxiedUrl line, which returns localhost, and thus the redirect induced by getLoginFlow (to /self-service/login/browser) is handled by my app (via the interceptor in the ory middleware).

However in production, which is not in Vercel at all let alone a vercel.app domain (we're on Azure), we bump into the following clause owing to NODE_ENV == "production"

elements/packages/nextjs/src/utils/sdk.ts

Lines 52 to 55 in a708dd0

	if (isProduction()) {
	// In production, we use the production custom domain
	return orySdkUrl()
	}

The problem is that our app is not hosted by Ory. We need this redirect to be back to https://ourdomain.com like it is to https://localhost in development. But we can't set up the custom domain in Ory to serve the orySdk from https://ourdomain.com, because that needs to point to our app in Azure.

---

In terms of the solution, for NextJS its unclear to me that you want any special handling here at all. guessPotentiallyProxiedOrySdkUrl is only used by what appear to be server-side-nextjs specific methods that redirect to self-service/, which is handled by the ory middleware. So I think you want to just get rid of guessPotentiallyProxiedOrySdkUrl and always use getPublicUrl.

[evantahler]

We are hitting the same problem at arcade.dev ...

[aeneasr]

In Vercel we have a production and a staging environment. This works fine for our production environment. But in our staging environment the user is sent to the wrong link, e.g. xyz.vercel.app because the logic in this function causes the us to hit this line which sets our sdk url as the incorrect address:

Does your staging build not use NODE_ENV=production?

However in production, which is not in Vercel at all let alone a vercel.app domain (we're on Azure), we bump into the following clause owing to NODE_ENV == "production"

I don't understand your problem - if you bump into this section of the code just set the environment variable correctly?

We are hitting the same problem at arcade.dev ...

Please provide a reproducible example like in the other posts so we understand the problem, thanks!

[vinckr]

@evantahler To add to the above - as a customer you also have access to dedicated support, please open a ticket. It will get it resolved a lot quicker...

[jonas-jonas]

@ibeckermayer, I have taken a look at your configuration, and I am not quite sure if I understand the issue you're running into.

To me, this seems like a misconfiguration in your project, not a bug in the code.

We only use guessPotentiallyProxiedOrySdkUrl to talk to the Ory project directly. Not your own domains. For development mode, this needs to be localhost, because of cookies and the middleware we provide that actually forwards these requests to your Ory project. But in production(-like) environments, this needs to be the CNAME you configured in your Ory project. This is, again, because of cookies:

Ory's APIs issue CSRF and session cookies on the domains the user is on. It cannot do this for domains that are not subdomains of your "main" domain used by your application, because third party cookies are very unreliable and work differently in every browser.

Now, some parts of the Ory flows redirect back to your configured UI, and this can be on any (sub-)domain you want as long as we can set cookies on it. But the user's browser first needs to hit Ory APIs for us to set the cookies.

So: in production-like environments, set the ORY_SDK_URL env variable to your project's CNAME and make it's a subdomain of your main app (e.g. auth.my.app or account.my.app).

[ibeckermayer]

I don't understand your problem - if you bump into this section of the code just set the environment variable correctly?

That variable is set correctly, in the sense that it's set to our ORY_SDK_URL (e.g. https://clever-taussig-xbcwhlp8ws.projects.oryapis.com). The problem is, this function is deciding a redirect url, and we don't ever want our users to be redirected to an Ory hosted page. We are using the ory nextjs components in our application, we only ever want them to redirected to our application.

We only use guessPotentiallyProxiedOrySdkUrl to talk to the Ory project directly. Not your own domains.

I think you're mistaken about this. We have a next.js component that is the example given in getLoginFlow, verbatim:

elements/packages/nextjs/src/app/login.ts

Lines 22 to 40 in b754057

	* export default async function LoginPage(props: OryPageParams) {
	* const flow = await getLoginFlow(config, props.searchParams)
	*
	* if (!flow) {
	* return null
	* }
	*
	* return (
	* <Login
	* flow={flow}
	* config={config}
	* components={{
	* Card: {
	* Header: CardHeader,
	* },
	* }}
	* />
	* )
	* }

That function calls guessPotentiallyProxiedOrySdkUrl

elements/packages/nextjs/src/app/login.ts

Lines 59 to 61 in b754057

	guessPotentiallyProxiedOrySdkUrl({
	knownProxiedUrl: await getPublicUrl(),
	}),

to get the baseUrl parameter of the getFlowFactory function.

elements/packages/nextjs/src/app/flow.ts

Line 32 in b754057

baseUrl: string,

That parameter ultimately culminates in a browser redirect:

elements/packages/nextjs/src/app/flow.ts

Lines 44 to 49 in b754057

	const redirectTo = new URL(route, baseUrl)
	redirectTo.search = new URLSearchParams({
	...params,
	flow: useFlowId,
	}).toString()
	return redirect(redirectTo.toString(), RedirectType.replace)

This is where our problem lies. In development, that redirect is our public url (e.g. localhost:3000) which means the new flow id gets routed through the ory middleware and everything works as expected. However the logic of guessPotentiallyProxiedOrySdkUrl means that in production, that redirect becomes the ory sdk url, which is something like https://clever-taussig-xbcwhlp8ws.projects.oryapis.com, which points to Ory's servers. It makes no difference whether that's https://clever-taussig-xbcwhlp8ws.projects.oryapis.com or whether I've configured my DNS such that it's https://auth.mydomain.com -- either way, it's a browser redirect to Ory servers, which my users should never browse to directly.

If we add yarn patch like

Details

diff --git a/dist/app/index.js b/dist/app/index.js
index d4ade92a6897ee5f111619b7daf0b6d0a761fded..56a65f33e6d781d547dedcfd518414a9aff7581d 100644
--- a/dist/app/index.js
+++ b/dist/app/index.js
@@ -190,9 +190,7 @@ async function getLoginFlow(config, params) {
       initOverrides
     ),
     clientFetch.FlowType.Login,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.login_ui_url
   );
 }
@@ -204,9 +202,7 @@ async function getRegistrationFlow(config, params) {
       initOverrides
     ),
     clientFetch.FlowType.Registration,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.registration_ui_url
   );
 }
@@ -218,9 +214,7 @@ async function getRecoveryFlow(config, params) {
       initOverrides
     ),
     clientFetch.FlowType.Recovery,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.recovery_ui_url
   );
 }
@@ -232,9 +226,7 @@ async function getVerificationFlow(config, params) {
       initOverrides
     ),
     clientFetch.FlowType.Verification,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.verification_ui_url
   );
 }
@@ -246,9 +238,7 @@ async function getSettingsFlow(config, params) {
       initOverrides
     ),
     clientFetch.FlowType.Settings,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.settings_ui_url
   );
 }
@@ -257,10 +247,7 @@ async function getLogoutFlow({
 } = {}) {
   var _a;
   const h = await headers.headers();
-  const knownProxiedUrl = await getPublicUrl();
-  const url = guessPotentiallyProxiedOrySdkUrl({
-    knownProxiedUrl
-  });
+  const url = await getPublicUrl();
   return serverSideFrontendClient().createBrowserLogoutFlow({
     cookie: (_a = h.get("cookie")) != null ? _a : "",
     returnTo
diff --git a/dist/app/index.mjs b/dist/app/index.mjs
index da6b25477c72c6e828734a05ede2979dc7fca911..51b648b15ca966c27d49b1a1c3ac5ba6f9041f8c 100644
--- a/dist/app/index.mjs
+++ b/dist/app/index.mjs
@@ -188,9 +188,7 @@ async function getLoginFlow(config, params) {
       initOverrides
     ),
     FlowType.Login,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.login_ui_url
   );
 }
@@ -202,9 +200,7 @@ async function getRegistrationFlow(config, params) {
       initOverrides
     ),
     FlowType.Registration,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.registration_ui_url
   );
 }
@@ -216,9 +212,7 @@ async function getRecoveryFlow(config, params) {
       initOverrides
     ),
     FlowType.Recovery,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.recovery_ui_url
   );
 }
@@ -230,9 +224,7 @@ async function getVerificationFlow(config, params) {
       initOverrides
     ),
     FlowType.Verification,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.verification_ui_url
   );
 }
@@ -244,9 +236,7 @@ async function getSettingsFlow(config, params) {
       initOverrides
     ),
     FlowType.Settings,
-    guessPotentiallyProxiedOrySdkUrl({
-      knownProxiedUrl: await getPublicUrl()
-    }),
+    await getPublicUrl(),
     config.project.settings_ui_url
   );
 }
@@ -255,10 +245,7 @@ async function getLogoutFlow({
 } = {}) {
   var _a;
   const h = await headers();
-  const knownProxiedUrl = await getPublicUrl();
-  const url = guessPotentiallyProxiedOrySdkUrl({
-    knownProxiedUrl
-  });
+  const url = await getPublicUrl();
   return serverSideFrontendClient().createBrowserLogoutFlow({
     cookie: (_a = h.get("cookie")) != null ? _a : "",
     returnTo

everything works for us, including in production.

There are no cookie issues in this nextjs case, because afaict Ory is never sending cookies directly to us in the browser. IIUC all cookies are being set in calls that get intercepted by the ory middleware (which lives server side)

elements/packages/nextjs/src/middleware/middleware.ts

Lines 46 to 56 in b754057

	export async function proxyRequest(
	request: NextRequest,
	options: OryMiddlewareOptions,
	) {
	const match = [
	"/self-service",
	"/sessions/whoami",
	"/ui",
	"/.well-known/ory",
	"/.ory",
	]

and domains are rewritten before being returned to the browser:

elements/packages/nextjs/src/middleware/middleware.ts

Lines 102 to 114 in b754057

	// Modify cookie domain
	if (upstreamResponse.headers.get("set-cookie")) {
	const cookies = processSetCookieHeaders(
	request.nextUrl.protocol,
	upstreamResponse,
	options,
	request.headers,
	)
	upstreamResponse.headers.delete("set-cookie")
	cookies.forEach((cookie) => {
	upstreamResponse.headers.append("Set-Cookie", cookie)
	})
	}

@jonas-jonas I've created an app with our basic project structure here:

https://github.com/ibeckermayer/ory-reproducible

(These codepaths are pretty difficult to follow, particularly with the added complexity of nextjs server vs client and the ory middleware proxy; I certainly could be mistaken, but you may be confusing the nextjs app with the workings of a SPA react app).

[aeneasr]

either way, it's a browser redirect to Ory servers, which my users should never browse to directly.

Actually, you should ALWAYS point users DIRECTLY to your Ory CNAME and NEVER proxy requests to Ory, as it significantly weakens our ability to protect your login from bots and malicious actors.

The ORY_SDK_URL should generally point to your cname, not to the oryapis.com domain (oryapis only during development). We probably have to clarify this in our docs @unatasha8 @wassimoo

Instead, you set your ORY_SDK_URL to your Ory Network CNAME (e.g. ory.domain.com) and set your default_redirect_url to your application's main entrypoint.

[ibeckermayer]

Actually, you should ALWAYS point users DIRECTLY to your Ory CNAME and NEVER proxy requests to Ory, as it significantly weakens our ability to protect your login from bots and malicious actors.

If this is the case then why do you provide the Login react component, and why does your official nextjs middleware proxy requests to Ory? Are you saying that you don't support self-hosting the login page (in which case, again, why would you provide an official React component seemingly just for that purpose?)

I think you're mistaken, and that you do support what I'm trying to do, but only for deploying the app to Vercel:

elements/packages/nextjs/src/utils/sdk.ts

Lines 31 to 50 in b754057

	if (getEnv("VERCEL_ENV")) {
	// We are in vercel
	// The domain name of the generated deployment URL. Example: *.vercel.app
	// This is only available for preview deployments on Vercel.
	if (!isProduction() && getEnv("VERCEL_URL")) {
	return `https://${getEnv("VERCEL_URL")}`.replace(/\/$/, "")
	}
	const productionUrl = getEnv("VERCEL_PROJECT_PRODUCTION_URL") || ""
	if (isProduction() && productionUrl.indexOf("vercel.app") > -1) {
	// This is a production deployment on Vercel without a custom domain, so we use the vercel app domain.
	return `https://${productionUrl}`.replace(/\/$/, "")
	}
	// This is sometimes set by the render server.
	if (process.env["__NEXT_PRIVATE_ORIGIN"]) {
	return process.env["__NEXT_PRIVATE_ORIGIN"].replace(/\/$/, "")
	}
	}

If you think otherwise, can you point me to specifically what's wrong with the reproducible example I provided?

https://github.com/ibeckermayer/ory-reproducible

[aeneasr]

In vercel we only support it for local dev and preview environments where you cant easily set a custom domain. In production vercel you set the SDK_URL to your cname.

It sounds like you may be mixing up the different options, which I understand because it‘s not well documented. Ideally reach out to a support person to figure out exactly how to set it up. I‘m sure your use case works, it‘s just not configured correctly on your end