supabase.auth.api.getUserByCookie() doesn't work in Next.JS server-side environment

[vklimontovich]

Bug report

Describe the bug

supabase.auth.api.getUserByCookie() doesn't work in Next.JS server-side environment (_middleware.ts)

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Create a supabase project
2. Create a Next.JS project
3. Create

Add following code to _middleware.ts

export async function middleware(req: NextRequest, ev: NextFetchEvent) {
    let supabase = createClient(...);
    let user = await supabase.auth.api.getUserByCookie(req);
    console.log('Auth ', user)
}

4. See logs

Auth  {
  user: null,
  data: null,
  error: ReferenceError: XMLHttpRequest is not defined
      at eval (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:462:17)
      at new Promise (<anonymous>)
      at fetch (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:455:12)
      at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:44:63)
      at new Promise (<anonymous>)
      at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:43:16)
      at Generator.next (<anonymous>)
      at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:16:71)
      at new Promise (<anonymous>)
      at __awaiter (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:12:12)
}

Expected behavior

getUserByCookie() should either work (use fetch() internally instead of XMLHttpRequest), OR message should be more clear (check the presence of XMLHttpRequest in getUserByCookie() and throw Sorry, you shouldn't call this method in server side environment

System information

Next version is 12.0.1

Additional context

Add any other context about the problem here.

[vklimontovich]

FYI, this workaroung does the job:

    let supabase = createClient(supabaseUrl, supabaseKey);
    let token = req.cookies['sb:token'];
    if (!token) {
        return 
    }
    let authRequestResult = await fetch(`${supabaseUrl}/auth/v1/user`, {
        headers: {
            'Authorization': `Bearer ${token}`,
            'APIKey': supabaseKey
        }
    });

[kiwicopple]

Hmm, odd since we're using cross-fetch: https://github.com/supabase/gotrue-js/blob/c213d2f02895248fc8d601a599116531be16071d/src/lib/fetch.ts#L1

I think the middleware is hosted on Cloudflare workers, so the other workaround is here: https://github.com/supabase/supabase/tree/master/examples/with-cloudflare-workers

[vklimontovich]

I haven't deployed the app yet, so I believe that Cloudflare has nothing do to with it. It's reproducible with local next dev. I'll try to make an isolated example and maybe suggest a patch

[vklimontovich]

Here's an isolated example: https://github.com/vklimontovich/supabase-nextjs-middleware

[saltcod]

Not sure if the same issue or if I'm doing something wrong but:

I'm trying to use supabase.auth.api.getUserByCookie() in getServerSideProps and the user is always null.

export async function getServerSideProps({ req }) {
	const { user } = await supabase.auth.api.getUserByCookie(req);

	console.log({ user }); // always null

	if (!user) {
		return {
			props: {},
		};
	}

	return { props: { user } };
}

BUT! if I check client-side, I do have a user:

useEffect(() => { 
	checkUser();
}, []);


async function checkUser() {
	const user = await supabase.auth.user();
	console.log(user); // got a user here
}```

[vklimontovich]

@saltcod have you set server cookie from client-side code? We published a post today, with a step-by-step guide on how to make next.js middleware work with Supabase auth: https://jitsu.com/blog/supabase-nextjs-middleware

[kiwicopple]

Thanks for this @vklimontovich - I see also that you have the buggy code commented out in the example. We have rolled out the fix where you can provide a custom fetch implementation (since cross-fetch isn't working in Cloudflare Workers):

https://supabase.io/docs/reference/javascript/initializing#custom-fetch-implementation

You should be able to initialise the client like this:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient('https://xyzcompany.supabase.co', 'public-anon-key', { 
  fetch: fetch 
})

And after that supabase.auth.api.getUserByCookie(req) shouldn't be a problem

[emilioschepis]

@kiwicopple should that already be working with Next.js's fetch?

// src/supabaseClient.ts
import { createClient } from "@supabase/supabase-js";

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL as string;
const supabaseAnonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY as string;

const supabase = createClient(supabaseUrl, supabaseAnonKey, {
  fetch: fetch,
});

export default supabase;

I have this simple configuration, but I still get an error that refers to cross-fetch when checking the auth in a middleware function.

{
    token: null,
    user: null,
    data: null,
    error: ReferenceError: XMLHttpRequest is not defined
        at eval (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:462:17)
        at new Promise (<anonymous>)
        at fetch (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:455:12)
        at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:44:13)
        at new Promise (<anonymous>)
        at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:43:16)
        at Generator.next (<anonymous>)
        at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:16:71)
        at new Promise (<anonymous>)
        at __awaiter (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:12:12)
}

I have the latest version of supabase (1.28.0).

[NixBiks]

Same here @emilioschepis

[kiwicopple]

I've tested with the updated supabase-js on @vklimontovich 's demo above, and created a PR here:

https://github.com/jitsucom/supabase-nextjs-middleware/pull/1/files

I can confirm on this PR I'm not seeing this issue any more. Perhaps you can compare with your own implementation to see if there is anything missing?

[NixBiks]

Odd. I have this in my _middleware.ts

import { supabase } from "@/services/supabase";
import { NextRequest, NextResponse } from "next/server";


export async function middleware(req: NextRequest) {
  const {user, token, error} = await supabase.auth.api.getUserByCookie(req)
  console.log(error)  
   ...

The error is ReferenceError: XMLHttpRequest is not defined

And this is how I export my supabase client

import { createClient } from "@supabase/supabase-js";

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL;
const supabaseAnonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY;

if (!supabaseUrl || !supabaseAnonKey)
  throw new Error(
    "Need to set NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY"
  );

export const supabase = createClient(supabaseUrl, supabaseAnonKey, {
  fetch: fetch
});

Running v1.28.0. Am I missing something obvious here?

[vklimontovich]

Very weird, @kiwicopple's PR didn't work for me as well. I tried to replace custom fetch with:

  return createClient(process.env.NEXT_PUBLIC_SUPABASE_URL, process.env.NEXT_PUBLIC_SUPABASE_KEY, {
    // @ts-ignore
    fetch: (...args) => {
      console.log("Args", args)
    },
  })

And I'm still seeing same error (meaning custom fetch wasn't passed to gotrue-js):

Authorization error, redirecting to login page ReferenceError: XMLHttpRequest is not defined
    at eval (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js:462:17)
    at new Promise (<anonymous>)
    at fetch (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js:455:12)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js:44:13)
    at new Promise (<anonymous>)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js:43:16)
    at Generator.next (<anonymous>)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js:16:71)
    at new Promise (<anonymous>)
    at __awaiter (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js:12:12)

(I did rm -rf node_modules && rm -rf yarn.lock && yarn install to make sure all packages are uptodate)

[NixBiks]

Could this be M1 related somehow?

[NixBiks]

Could this be M1 related somehow?

No. Just tested on my ubuntu desktop and I'm getting the same error. Versions:

❯ yarn info | grep supabase-js -A 8
├─ @supabase/supabase-js@npm:1.28.0
│  ├─ Version: 1.28.0
│  │
│  └─ Dependencies
│     ├─ @supabase/gotrue-js@npm:^1.21.0 → npm:1.21.1
│     ├─ @supabase/postgrest-js@npm:^0.35.0 → npm:0.35.0
│     ├─ @supabase/realtime-js@npm:^1.2.1 → npm:1.2.1
│     └─ @supabase/storage-js@npm:^1.5.0 → npm:1.5.0

[thorwebdev]

It sounds like simply importing cross-fetch causes this error to be thrown: lquixada/cross-fetch#69

If that's the case, the above mentioned workaround might be your best bet for now: #3783 (comment)

Or you can try the patch-package approach from https://github.com/supabase/supabase/tree/master/examples/with-cloudflare-workers

[kiwicopple]

after more thorough testing I found the error was persisiting. sorry about the false posititve.

I added another commit to the PR, based on Thor's link to the cross-fetch package - in particular, this comment. I can confirm that this works in Next.js middleware, on a local environment.

I'll follow up on the linked package and see if that change is OK to merge

[gabrielsestrem]

Thanks @kiwicopple . I am also waiting for this to implement the _middleware.ts to our pages that requires SSR for Authentication.

[mauricedesaxe]

supabase.auth.api.getUserByCookie(req) doesn't work in getServerSideProps (only in production for me either).

I've tried so many things, including what the OP wrote in this article here.

Any updates on this?

[KushibikiMashu]

Error still occurs in middleware on Next.js dev server.

"next": "^12.0.4"
"@supabase/supabase-js": "^1.28.5"

ReferenceError: XMLHttpRequest is not defined
    at eval (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:462:17)
    at new Promise (<anonymous>)
    at fetch (webpack-internal:///./node_modules/cross-fetch/dist/browser-ponyfill.js?d2fb:455:12)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:44:13)
    at new Promise (<anonymous>)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:43:16)
    at Generator.next (<anonymous>)
    at eval (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:16:71)
    at new Promise (<anonymous>)
    at __awaiter (webpack-internal:///./node_modules/@supabase/gotrue-js/dist/module/lib/fetch.js?85f4:12:12)

[kiwicopple]

ReferenceError: XMLHttpRequest is not defined

If this is the error then you probably want to provide a different Fetch provider: https://supabase.com/docs/reference/javascript/initializing#custom-fetch-implementation

[yudyananda]

ReferenceError: XMLHttpRequest is not defined

If this is the error then you probably want to provide a different Fetch provider: https://supabase.com/docs/reference/javascript/initializing#custom-fetch-implementation

@kiwicopple it work like a charm in my middleware but somehow i cannot longer fetch the table in the client-side. any idea?

export const supabase = createClient(supabaseUrl, supabaseToken, {
   fetch,
});

const sessionUser = supabase.auth.user();
const { data: profile } = await supabase
    .from('profile')
    .select('*')
    .eq('id', sessionUser.id)
    .single();
   console.log('profile :', profile);  // always null

[kiwicopple]

It seems that might be an unrelated issue @yudyananda - you're welcome to start a new issue (so this one doesnt get sidetracked). It could be any of: not authenticated, RLS, sessionUser.id is not returned, there could be an error returned const { data: profile, error }

[tchief]

@yudyananda @kiwicopple I noticed this as well. As a workaround used 2 instances of SupabaseClient: one for client side (without custom fetch) and one for server side with this PR applied.

[Murkrage]

I was suffering from the same issue server side as has been mentioned a couple times here: getUserByCookie() returns null even though the client returns a user as expected. I'm using a magic link as my login method and what I noticed was that my session cookie wasn't set.

I found this post on dev.to that solves my problem. OP uses supabase.auth.onAuthStateChange() and supabase.auth.api.setAuthCookie() to manually set the supabase cookie client side. Once that's happened the server correctly fetches the user.

The following is added to the _app.tsx:

useEffect(() => {
    const { data: authListener } = supabase.auth.onAuthStateChange(
      (event, session) => {
        if (event === "SIGNED_IN") {
          updateSupabaseCookie(event, session);
        }
      }
    );

    return () => {
      authListener?.unsubscribe();
    };
  });

  async function updateSupabaseCookie(event: string, session: Session | null) {
    await fetch("/api/auth", {
      method: "POST",
      headers: new Headers({ "Content-Type": "application/json" }),
      credentials: "same-origin",
      body: JSON.stringify({ event, session }),
    });
  }

The following is added to /api/auth.ts:

const handler = (req: NextApiRequest, res: NextApiResponse) => {
    supabase.auth.api.setAuthCookie(req, res);
};

The supabase.auth.api.XXX methods aren't documented anywhere. As far as I can tell at least. It seems to do the trick, though. Not sure if this is the desired implementation, would love to get feedback on this.

[ingokpp]

I have another workaround. A one liner 😊

supabase.auth.setAuth(req.cookies['sb:token']);

This requires that the cookie is set on auth change like mentioned before :)

[Hallidayo]

I was suffering from the same issue server side as has been mentioned a couple times here: getUserByCookie() returns null even though the client returns a user as expected. I'm using a magic link as my login method and what I noticed was that my session cookie wasn't set.

I found this post on dev.to that solves my problem. OP uses supabase.auth.onAuthStateChange() and supabase.auth.api.setAuthCookie() to manually set the supabase cookie client side. Once that's happened the server correctly fetches the user.

The following is added to the _app.tsx:

useEffect(() => {
    const { data: authListener } = supabase.auth.onAuthStateChange(
      (event, session) => {
        if (event === "SIGNED_IN") {
          updateSupabaseCookie(event, session);
        }
      }
    );

    return () => {
      authListener?.unsubscribe();
    };
  });

  async function updateSupabaseCookie(event: string, session: Session | null) {
    await fetch("/api/auth", {
      method: "POST",
      headers: new Headers({ "Content-Type": "application/json" }),
      credentials: "same-origin",
      body: JSON.stringify({ event, session }),
    });
  }

The following is added to /api/auth.ts:

const handler = (req: NextApiRequest, res: NextApiResponse) => {
    supabase.auth.api.setAuthCookie(req, res);
};

The supabase.auth.api.XXX methods aren't documented anywhere. As far as I can tell at least. It seems to do the trick, though. Not sure if this is the desired implementation, would love to get feedback on this.

I have the same sort of implementation as this but in a AuthContext and this for me works well with the cookie being set manually

[thorwebdev]

I'd recommend using https://github.com/supabase-community/supabase-auth-helpers/blob/main/src/nextjs/README.md going forward.

[Murkrage]

@thorwebdev Is there a way to refresh the user's token so they aren't logged out after the max expiry of 1 week using the auth-helper? That's the one thing I'm struggling with right now.

[thorwebdev]

@Murkrage the auth helper library stores the account_token as well as the refresh_token in secure server cookies, and automatically refreshes the account_token when it is expired. This way the user should theoretically never get logged out as the refresh_token doesn't expire.

Are you saying you've had issues with that using the auth helpers, or this is a problem you're currently facing not using the auth helpers?

NOTE: by default the cookies will expire after 8h. If you want the user to stay logged in longer, you can set the lifetime in the cookieOptions like so: https://github.com/vercel/nextjs-subscription-payments/pull/104/files

[thorwebdev]

Closing this out, as mentioned, please use https://github.com/supabase-community/supabase-auth-helpers/blob/main/src/nextjs/README.md going forward and open issues there if you encounter any. Thanks 💚

[IHIutch]

Updated link https://github.com/supabase-community/auth-helpers/blob/main/packages/nextjs/README.md

[IHIutch]

I'm a little confused by this suggestion because the documented example uses the @supabase/ui Auth which I've found tends to obfuscate what is actually happening when authenticating. I appreciate that this community package appears to solve some issues (Does it actually solve the _middleware issue? I'm not seeing that confirmed anywhere) but I still feel a bit in the dark on some other things.

My 2 cents:

1. Am I required/expected to use @supabase/ui Auth when handling auth when using Supabase? That feels odd to me.
2. Using a community package to circumvent an issue with Supabase and NextJS doesn't feel like a "Closed" worthy resolution, imho
   • Further, having to install 2 additional packages feels like a weird solution. Temporary, sure, but as a permanent solution?
3. In my app specifically, I use a /api/auth/register route to create a user in my DB and sign them in. It's unclear to me how I'd do that using the community package

I don't mean to offend, I'm an intermediate developer at best, I'm just trying to understand and leverage the incredible framework that is Supabase. But as such, I'm really struggling to understand the solution here. My app works fine, with everything except getUserByCookie when using _middleware, so this feels like an additional piece of complexity to understand and keep up with as things change.

If anyone can shed some light, I'm eager to understand better, thanks.

[thorwebdev]

Thanks for the feedback @IHIutch, I understand your frustration, a bunch of things are in flux atm which creates this less than ideal experience 😞

1. Am I required/expected to use @supabase/ui Auth when handling auth when using Supabase? That feels odd to me.

Not at all a requirement. The Auth UI Element is solely meant to make things faster/easier by giving you a prebuilt UI, but not at all a requirement. You can always built your custom UI if you prefer.

2. Using a community package to circumvent an issue with Supabase and NextJS doesn't feel like a "Closed" worthy resolution, imho

It's technically not an issue, or at least not a bug, since you very well can set the cookies yourself if you want. It's just not the easiest thing to do. So having some convenience libraries to help you with this is our philosophy here.

Further, having to install 2 additional packages feels like a weird solution. Temporary, sure, but as a permanent solution?

Again, all of these are optional and are meant as a convenience. the @supabase/auth-helpers are non-ui helpers and the @supabase/auth-ui (https://github.com/supabase-community/auth-ui) is where the Auth UI Elements will be moved to in the future.

Does it actually solve the _middleware issue

It does, have a look at the example here: https://github.com/supabase-community/auth-helpers/blob/main/examples/nextjs/pages/middleware-protected/_middleware.ts

Sorry, we're working on improving this experience, just a lot of moving parts right now. We really appreciate your feedback and will use it to improve things!

[IHIutch]

Thanks @thorwebdev, I appreciate the response. Genuinely, Supabase has such a great community and I appreciate the conversation.

[cagils]

What is the current suggestion if I just want to check for authenticated user in the getServerSideProps (not using next js api for auth) and if I do not prefer to use auth-helpers?

[kiwicopple]

If you prefer not to use the helpers, you would probably want to follow the same process in the helpers code. eg: set the Auth token inside a cookie, and then extract the value of the cookie inside getServerSideProps - the idea of the helpers isn't to do anything unique, it's simply to provide a library which will follow the same steps that you'd do yourself

[Jordaneisenburger]

I was suffering from the same issue server side as has been mentioned a couple times here: getUserByCookie() returns null even though the client returns a user as expected. I'm using a magic link as my login method and what I noticed was that my session cookie wasn't set.

I found this post on dev.to that solves my problem. OP uses supabase.auth.onAuthStateChange() and supabase.auth.api.setAuthCookie() to manually set the supabase cookie client side. Once that's happened the server correctly fetches the user.

The following is added to the _app.tsx:

useEffect(() => {
    const { data: authListener } = supabase.auth.onAuthStateChange(
      (event, session) => {
        if (event === "SIGNED_IN") {
          updateSupabaseCookie(event, session);
        }
      }
    );

    return () => {
      authListener?.unsubscribe();
    };
  });

  async function updateSupabaseCookie(event: string, session: Session | null) {
    await fetch("/api/auth", {
      method: "POST",
      headers: new Headers({ "Content-Type": "application/json" }),
      credentials: "same-origin",
      body: JSON.stringify({ event, session }),
    });
  }

The following is added to /api/auth.ts:

const handler = (req: NextApiRequest, res: NextApiResponse) => {
    supabase.auth.api.setAuthCookie(req, res);
};

The supabase.auth.api.XXX methods aren't documented anywhere. As far as I can tell at least. It seems to do the trick, though. Not sure if this is the desired implementation, would love to get feedback on this.

Just to confirm, this manual work is still needed even when using https://github.com/supabase-community/auth-helpers/tree/main/packages/nextjs#basic-setup correct ?

[thorwebdev]

Nope, the auth helpers take care of this for you vis the UserProvider component that you wrap your app in.

[Jordaneisenburger]

Mhh thats interesting because without it the magic link login doesn't work the first time and you need to manually refresh the page or it simply doesnt login at all in production.

It's possible that I might be doing something wrong ofcourse. But I'm pretty sure simply using the UserProvider doesnt cover all cases perse

[thorwebdev]

The magic link redirect will need to go to a page that has the UserProvider first in order to set the cookie. Only after that the SSR stuff will work.

[tomedalya]

We published a post today, with a step-by-step guide on how to make next.js middleware work with Supabase auth: https://jitsu.com/blog/supabase-nextjs-middleware

@vklimontovich seems like this does not work anymore with the newer version of supabase (1.35.6)
the token is not under sb:token and even after changing to sb-access-token there is an error
Error [TypeError]: Cannot delete property 'Symbol(set-cookie)' of #<HeadersList2>

[wiesson]

Nextjs 13 has been released and they provide a new way of fetching data.

// app/page.js
import { use } from 'react';

async function getData() {
  const res = await fetch('...');
  const name: string = await res.json();
  return name;
}

export default function Page() {
  // This value is fully typed
  // The return value is *not* serialized
  // so you can return Date, Map, Set, etc.
  const name = use(getData());

  return '...';
}

(taken from here https://nextjs.org/blog/next-13#data-fetching)

I have a similar error:

wait  - compiling /(app)/app/requests/page (client and server)...
warn  - ./node_modules/.pnpm/[email protected]/node_modules/node-fetch/lib/index.js
Module not found: Can't resolve 'encoding' in '/Users/wiese/Dev/tm/next-13/node_modules/.pnpm/[email protected]/node_modules/node-fetch/lib'

pnpm why node-fetch shows that cross-fetch uses fetch2.6.7

If I try to use another fetch implementation, I get ESM import errors. With node18, it works btw. (still errors, but the page renders and supabase client works)

[thorwebdev]

Next.js 13 discussion moved -> supabase/auth-helpers#341