Error: Invalid UTF-8 sequence crashing Vercel

[k2xl]

Bug report

• [x ] I confirm this is a bug with Supabase, not with my own application.
• [ x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

On version
"@supabase/ssr": "^0.4.0",

Randomly been getting these errors for my app. Only solution is to destroy my cookies and refresh.

Error: Invalid UTF-8 sequence
at (node_modules/@supabase/ssr/dist/module/utils/base64url.js:187:0)
at (node_modules/@supabase/ssr/dist/module/utils/base64url.js:90:0)
at (node_modules/@supabase/ssr/dist/module/cookies.js:246:30)
at (node_modules/@supabase/auth-js/dist/module/lib/helpers.js:100:0)
at (node_modules/@supabase/auth-js/dist/module/GoTrueClient.js:787:0)
at (node_modules/@supabase/auth-js/dist/module/GoTrueClient.js:768:0)
at (node_modules/@supabase/auth-js/dist/module/GoTrueClient.js:714:0)

This us a super weird bug where when I visit my website it just literally crashes. However clearing my cookies the website works for a bit then stops.

To Reproduce

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

I do not know how the bug occurs.

Screenshots

If applicable, add screenshots to help explain your problem.

System information

Running on a nextjs app with supabase. My app allows google logins

[Nishchit14]

This is happening to me as well on the production app. Need to degrade the version asap.

[k2xl]

@Nishchit14 which version did you downgrade? I continuously get this error in production too

[Nishchit14]

@k2xl @supabase/ssr": "^0.0.10

[j4w8n]

@Nishchit14 @k2xl would you mind adding this option to all of your Supabase client-creation code, to see if it resolves the issue? Keep in mind that this will alter how the cookie is stored; so, if you are grabbing the cookie yourself, somewhere in your code, you'd need to change how that functions.

I'm not offering this as a long-term solution, but rather a test. Although, if it's a client option then it could be used long-term.

/* example only. this option is needed in all code that creates a client. */
export function createClient() {
  return createBrowserClient(process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookieEncoding: "raw"
    }
  )
}

base64:

raw:

Roughly how long is the time between failures?

[k2xl]

Trying and will get back to you
(Apologies, accidentally closed the task. reopened it now)

[k2xl]

Still occurs. Happens an hour or so in

[j4w8n]

I'm not sure what would be going on then. I went through every source file, and the only references I can find to base64url.js are when cookies are being encoded/decoded to/from base64 (or for tests).

And you're sure you added that option in every place that a Supabase client is created?

And the error is the same as the original?

[k2xl]

@j4w8n I added it to all the createClients that allow me to pass that cookieEncoding

  // Create a supabase client on the browser with project's credentials
  return createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    { cookieEncoding: 'raw' }
  );

const cookieStore = cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookieEncoding: 'raw',
      cookies: {
        get(name: string) {
          return cookieStore.get(name)?.value;
        },
        set(name: string, value: string, options: CookieOptions) {
          try {
            cookieStore.set({ name, value, ...options });
          } catch (error) {
            // The `set` method was called from a Server Component.
            // This can be ignored if you have middleware refreshing
            // user sessions.
          }
        },
        remove(name: string, options: CookieOptions) {
          try {
            cookieStore.set({ name, value: '', ...options });
          } catch (error) {
            // The `delete` method was called from a Server Component.
            // This can be ignored if you have middleware refreshing
            // user sessions.
          }
        },
      },
    }
  );

Initialization error: Error: Invalid UTF-8 sequence
    at stringFromUTF8 (webpack-internal:///(rsc)/./node_modules/@supabase/ssr/dist/module/utils/base64url.js:195:19)
    at stringFromBase64URL (webpack-internal:///(rsc)/./node_modules/@supabase/ssr/dist/module/utils/base64url.js:98:17)

[j4w8n]

@k2xl that's really strange. Can you verify the cookie is not being stored with a base64 prefix at the beginning?

[k2xl]

Actually the cookies still do begin with base64…

[j4w8n]

@k2xl Is this reproducible during dev on your machine, or is it only during prod on Vercel?

[k2xl]

Reproduces on dev and on prod

[fincha]

I have the same issue, but it happens to me only on prod... what a shame :(

    "@nuxtjs/supabase": "^1.4.1",

error stack

[nitro] [unhandledRejection] Error: Invalid UTF-8 sequence
    at stringFromUTF8 (/opt/render/project/src/.output/server/node_modules/@supabase/ssr/dist/main/utils/base64url.js:200:19)
    at stringFromBase64URL (/opt/render/project/src/.output/server/node_modules/@supabase/ssr/dist/main/utils/base64url.js:94:17)
    at Object.getItem (/opt/render/project/src/.output/server/node_modules/@supabase/ssr/dist/main/cookies.js:249:63)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async getItemAsync (/opt/render/project/src/.output/server/node_modules/@supabase/auth-js/dist/main/lib/helpers.js:134:19)
    at async SupabaseAuthClient.__loadSession (/opt/render/project/src/.output/server/node_modules/@supabase/auth-js/dist/main/GoTrueClient.js:800:34)
    at async SupabaseAuthClient._useSession (/opt/render/project/src/.output/server/node_modules/@supabase/auth-js/dist/main/GoTrueClient.js:781:28)
    at async SupabaseAuthClient._emitInitialSession (/opt/render/project/src/.output/server/node_modules/@supabase/auth-js/dist/main/GoTrueClient.js:1218:16)

PS: ok, it only happens, when I have this cookie... no idea how it happend. I haven't even deployed today.
PPS:

I have decoded this base64 cookie and have found probably the issue:

{"access_token":"eyJhb...Z3q0","token_type":"bearer","expires_in":3600,"expires_at":1729179524,"refresh_token":"LOt97s...ky-A","user":{"id":"8f71b6c8-32bb-40a0-b22e

Total length: 2379 characters (decoded)
I am using latest Version of firefox on macos.

it is not a valid JSON... the user id is not fully represended. Now idea how it happend.

[fincha]

Ok... my bad, I wondered why the first part of the cookie was decodeable and others not, so I combined it 😄 (what a hacker I am) anyway, the string was also decodeable.

I used this tool to decode: https://base64.guru/converter/decode

and I had this warning:

The character encoding was detected as “ISO-8859-1”, but the algorithm is inaccurate and there is a high probability that this is wrong. Because of this you can get the wrong results. To know for sure, please check the Character Encoding Detector tool.

at the end of the json I had this

ÓuCS£C�£#ã3�3Cs%¢"Â&�5öæöç�Ö÷W2#¦fÇ6W×Ð

this might be the issue

[Krovikan-Vamp]

My cookies also start with the "base64-" prefix and I have passed the cookieEncoding prop as noted above.

Are there any options other than downgrading the @supabase/ssr version?

Clearing the site data always resolves this error, though. After the session times out (an hour or so) I get the same error.

[fincha]

I "fixed" this for me, by deleting all the cookies and this issue never reappear, BUT i think I have an idea why it was present the first time, if you @Krovikan-Vamp could confirm one of this actions for you too, this will be the issue:

• you switched between users and one of the users has more information in token then the other
• you enriched/decreaed amount of information passed by token for single user

my idea is, if token was 4 cookies long, and is suddently 3 or the other way, it crashes, what makes totally sense IMHO.

[Krovikan-Vamp]

Hi @fincha, thanks for your insight! I notice the same thing that deleting all cookies resolves the issue; however only temporarily. This issue always comes back after the session times out (3600 seconds) and the user is on a page that checks supabase.auth.getUser()

I am not modifying the cookies/JWT via hooks or anything else. I also added the "cookieEncoding": "raw" prop, too. I already updated the codebase so I don't want to face any regressions by downgrading to @supabase/ssr": "^0.0.10 as suggested by @Nishchit14.

Anyone else found a solution to this? If it applies I am authenticating through Azure but have not been able to resolve from that end.

Thanks! 👾🚀

[j4w8n]

@Krovikan-Vamp did you get to a point where your first cookie doesn't start with base64-?

[ptts]

We're having the same issue:

In our case, the auth cookie is split into 3 parts: token.0, token.1 and token.2.

The combination of

• token.0 + token.1 is valid base64 ✅
• token.0 + token.2 is valid base64 ✅
• token.0 + token.1 + token.2 is invalid ❌

token.0 and token.2 have the same cookie expiry date, so apparently the have been created at the same time, token.1 has a different expiry date which is dated after the other two tokens.

Maybe Supabase detects that the first part can stay unchanged, only sets the second (.1) part and "forgets" to unset the third (.2) part?

[j4w8n]

I'm trying to reproduce this locally, with Google OAuth. Any secrets to getting the session large enough to be broken into three cookies? Right now it's only creating two for me.

[j4w8n]

I'm trying to reproduce this locally, with Google OAuth. Any secrets to getting the session large enough to be broken into three cookies? Right now it's only creating two for me.

I was able to add some extra user data.

[j4w8n]

@ptts I do find it interesting that your 2nd and 3rd cookies should've been able to be combined.

Your 1st is of size 3216, and then 3013 and 154. That should've only required two cookies, since 3013 and 154 are a total of 3167 - well below the max of 3216.

Right now, my first two cookies are 3216, then another of 1255.

@k2xl @fincha @Nishchit14 @Krovikan-Vamp whenever you have issues, do you see this cookie size anomaly?

[andreapiso]

Our users are facing this too - and it's pretty debilitating as it happens very often

[j4w8n]

I did find a mechanism in the cookie-chunking logic, to where it's possible to have a "middle" cookie size of less than the typical 3216. After the whole value is encoded with encodeURIComponent(), it tries to make sure it's not splitting a character escape sequence between cookie chunks.

All of that to say it's possible to have a couple of cookie sizes that could've been rolled into one cookie, but they were trying to do the above, so the content got split. If that makes sense.