Supabase + Sveltekit Auth

[akiarostami]

With Sveltekit's breaking update 10 days ago, I have not been able to get Supabase auth work with the new Sveltekit. Client side authentication works fine, but there's no way to call auth.api.setAuthCookie set the server cookies anymore.

Has anyone been able to the new sveltekit work with Supabase? I would very much appreciate some help. Perhaps the great Supabase team can create a sample app with sveltekit?

[GaryAustin1]

Not sure if he checks here, but go to Supabase Discord and shout out @silentworks with your question. He is a mod there and uses and comments on Sveltekit stuff a lot. He might be interested in this if he has not hit it yet.
I use Sveltekit, but static only so this does not hit me.
Edit: looks like github knew his handle.

[silentworks]

@akiarostami you can have a look at my application which I upgraded yesterday to use the latest SvelteKit. The main changes are that now you have to use the native Request over the custom one SvelteKit had implemented. So take a look at the following files:

hooks.js

I've abstracted most of the code from this into handleAuth.js to make it easier to use in various projects, the change in this file is from request to event both on the handle function and the getSession function.

handleAuth.js

In this file we now get the request from event.request and then use that everywhere, I've also removed the need to convert the toSvelteKitResponse function as we only need to resolve the response and send it back. I've also removed the whole convention of getting the request method using the _method in the code as this is no longer necessary with SvelteKit.

expressify.js

I've updated the toExpressRequest function to also take a body and changed how we retrieve values from the headers using the get method. In the toExpressResponse I've done a similar thing but also using the set method to set the values in the header. I had to update the status method to have a end function too as this was throwing an error.

I hope this is all helpful, you can clone the project to see how it works and just copy those 3 files into your own project and it should work as intended.

https://github.com/silentworks/waiting-list

Thanks for the ping @GaryAustin1.

[samuelstroschein]

Thanks for the clarification! I disabled SSR. I guess that's why I did not encounter any issues.

[ANorseDude]

@silentworks can't you do simple tutorial how to set sveltekit + supabase SSR/auth up? Seems to be quite a few people interesed in it.

[eikaramba]

@ANorseDude just look at the post below, there you find a complete solution with code

[ANorseDude]

@ANorseDude just look at the post below, there you find a complete solution with code

Cheers @eikaramba, I somehow missed that.

[silentworks]

@ANorseDude one of the reasons I've avoided doing tutorials at the moment is because SvelteKit has a moving goalpost, I'm waiting on Rich to announce v1.0.0-rc first.

[akiarostami]

@silentworks thanks for the solution. I played around with your code, and it definitely solves my "express" issue with the new format. Thank you for that.

I also found another approach by @eikaramba which was a great one, and it also solved the token time-out / refresh problem (which has been very annoying). I suggest taking a look at his code (which does need some cleanup). I can post my cleaned-up code here as well, if that helps.

[eikaramba]

thanks for the flowers ;) yeah sveltekit had some breaking changes since, but nothing one cannot quickly solve. please post your code here as well, if you have improved anything else i am also eager to know about it. :)

[silentworks]

@akiarostami I haven't had the token time-out/refresh problem with the way I'm doing it. I've logged into my app and left the tab open for over 2 hours, came back and started clicking around and was still getting data from Supabase. If possible can you provide some instructions on how to replicate this problem, please?

[akiarostami]

Below my code based on @eikaramba's code, modified toz work with the new breaking updates of sveltekit.

I have not fully tested all corners, but I haven't had any problem so far.

Auth.js

// $lib/auth.js
import { env } from '$utils/env';
import { createClient } from '@supabase/supabase-js';
import { goto } from '$app/navigation';
import * as cookie from 'cookie';

const db = createClient(env.VITE_SUPABASE_URL, env.VITE_SUPABASE_ANON_KEY);

export default db;

export const auth = db.auth;

export const signOut = async () => {
	await auth.signOut();
	await unsetAuthCookie();
	goto('/');
};

export const getCookie = (name, token, extra) => {
	const Blank = { path: '/', expires: new Date(0) };
	const DefaultOptions = {
		path: '/',
		httpOnly: true,
		secure: true,
		sameSite: 'strict',
		maxAge: 60 * 60 * 24 * 180, // default Max-Age, can be overwritten via extra
	};
	let options = { ...DefaultOptions, ...extra };

	return token ? cookie.serialize(name, token, options) : cookie.serialize(name, '', Blank);
};

export const blankCookies = () => {
	return [getCookie('refresh_token', null), getCookie('access_token', null), getCookie('expires_at', null)];
};

const setServerSession = async (event, session) => {
	console.log('Setting Server Session >>>', event, session);
	await fetch('/api/auth.json', {
		method: 'POST',
		headers: new Headers({ 'Content-Type': 'application/json' }),
		credentials: 'same-origin',
		body: JSON.stringify({ event, session }),
	});
};

export const setAuthCookie = async (session) => {
	await setServerSession('SIGNED_IN', session);
};
export const unsetAuthCookie = async () => {
	await setServerSession('SIGNED_OUT', null);
};

API

// $routes/api/auth.js
import { getCookie, blankCookies } from '$lib/auth';

export async function post({ request }) {
	let body = await request.json();
	let session = body.session;

	let setCookie = session
		? [
				getCookie('refresh_token', session['refresh_token'], { maxAge: session['expires_in'] }),
				getCookie('access_token', session['access_token'], { maxAge: session['expires_in'] }),
				getCookie('expires_at', session['expires_at'], { maxAge: session['expires_in'] }),
		  ]
		: blankCookies();

	return {
		status: 200,
		body: null,
		headers: { 'set-cookie': setCookie },
	};
}

export async function get({ request }) {
	const { user, authenticated } = await request.locals;
	// refer hooks to see how this got populated
	return {
		body: { user, authenticated },
	};
}

hooks

//hooks.js
import { auth, getCookie, blankCookies } from '$lib/auth';
import * as cookie from 'cookie';
import jwt from 'jsonwebtoken';

const ExpiryMargin = 1000;

// exchange the refresh token for an access token
async function refreshAccessToken(cookies) {
	const { data, error } = await auth.api.refreshAccessToken(cookies.refresh_token);
	if (error) {
		cookies.access_token = null;
		cookies.refresh_token = null;
		cookies.expires_at = null;
		throw error;
	}

	auth.setAuth(data.access_token); //needed so that server calls are authenticated

	cookies.access_token = data.access_token;
	cookies.refresh_token = data.refresh_token;
	cookies.expires_at = data.expires_at;

	return [
		getCookie('refresh_token', data.refresh_token, { maxAge: data.expires_in }),
		getCookie('access_token', data.access_token, { maxAge: data.expires_in }),
		getCookie('expires_at', data.expires_at, { maxAge: data.expires_in }),
	];
}

export const handle = async ({ event, resolve }) => {
	let cookies = cookie.parse(event.request.headers.get('cookie') || '');
	let setCookies = [];

	if (cookies.access_token || cookies.refresh_token) {
		if (cookies.expires_at < Math.floor(Date.now() / 1000) + ExpiryMargin) {
			console.log('Access token expired. Refreshing...');
			try {
				setCookies = await refreshAccessToken(cookies);
			} catch (err) {
				console.log(err);
				setCookies = blankCookies();
			}
		}
		const jwtPayload = cookies.access_token ? jwt.decode(cookies.access_token) : false;
		event.locals.authenticated = !!jwtPayload;
		event.locals.user = { email: jwtPayload?.email };
	}

	let response = await resolve(event);

	if (setCookies?.length > 0) {
		setCookies.forEach((cookie) => response.headers.append('set-cookie', cookie));
	}

	return response;
};

export async function getSession(request) {
	const { user, authenticated } = request.locals;
	return {
		user,
		authenticated,
	};
}

and finally add this to:

__layout.js

<script>
	import { session } from '$app/stores';
	import { auth, setAuthCookie, unsetAuthCookie } from '$lib/auth';

	auth.onAuthStateChange(async (event, _session) => {
		if (event !== 'SIGNED_OUT') {
			await setAuthCookie(_session);
			session.set({ user: _session.user, authenticated: !!_session.user });
		} else {
			session.set({ user: undefined, authenticated: false });
			await unsetAuthCookie();
		}
	});
</script>

This should address authentication, server-side cookies, and auto-refreshing the server-side cookies.

User object will be available in all pages via session.

[liamsanft]

btw i had a quite interesting issue on safari on ios too. Just food for thoughts (i don't necessarly believe this is the issue, but maybe who knows) safari is not setting a 3rd party domain cookie if you come from a redirect. e.g. you want to use oauth and then the flow is like this mywebsite -> apple.com (for oauth) -> mywebsite (now setting cookie for mywebsite)

in this case the cookie will not be set! in other browsers it works. Quite interesting, but there is an easy workaround. just let the page refresh itself again automatically

function buildquery(query){
  if(query && Array.from(query).length>0){
      return "?"+query.toString()+"&refresh=true";
  }else{
      return "?refresh=true";
  }
}

//in some endpoint first serve a blank page that refreshes itself again automatically
export async function get({ locals, request, url, params }) {
let cookies = cookie.parse(request.headers.get("cookie") || "");
if (!cookies.refresh_token) {
    if(!url.searchParams.get('refresh')){
      return {
        status: 200,
        body: `<html><head>
        <meta http-equiv="refresh" content="0; url=${buildquery(url.searchParams)}">
        </head></html>`
      };
    }
  }
//the actual code
...
}

This only happened to me when using "SameSite=Strict". If you use "SameSite=Lax", it should work in Safari.

[christopherreay]

__layout.js

<script>
	import { session } from '$app/stores';
        // SO I ADDED THIS LINE, obvs the function is called whenever the session is updated, im guessing
        session.subscribe((sessionData) => {console.log(sessionData) }); 

	import { auth, setAuthCookie, unsetAuthCookie } from '$lib/auth';

	auth.onAuthStateChange(async (event, _session) => {
		if (event !== 'SIGNED_OUT') {
			await setAuthCookie(_session); 
                        //THIS LINE WAS THROWING AN ERROR "must subscribe"
			session.set({ user: _session.user, authenticated: !!_session.user });
		} else {
			session.set({ user: undefined, authenticated: false });
			await unsetAuthCookie();
		}
	});
</script>

[christopherreay]

So I found what I think is a race condition in the code pasted above. And I hope that a slight alteration of how the auth.setAuth(...) is being used, will make it a bit more clear to people reading this, what is happening.

so, there is the line

auth.setAuth(data.access_token); //needed so that server calls are authenticated

in the hooks.

Now, to me this is very confusing, because resolve(event) is asynchronous. Therefore setting the setAuth to whatever is the latest JWT to be refreshed seems like it is not clearly gonna mean that the specified auth will be the one that processes the request.

Instead, what I have done is remove the setAuth from the refresh token code, and instead stored the access_token in the session.
Then, when the auth endpoint actually makes a call to supabase, I use setAuth to set the auth for the request to the token stored in the session.

This should be done everytime the the client is used, if there is any chance that it might happen during SSR.

in hooks.js

if (cookies.access_token || cookies.refresh_token) {
		if (cookies.expires_at < Math.floor(Date.now() / 1000) + ExpiryMargin) {
			console.log('Access token expired. Refreshing...');
			try {
				setCookies = await refreshAccessToken(cookies);
			} catch (err) {
				console.log(err);
				setCookies = blankCookies();
			}
		}
		const jwtPayload = cookies.access_token ? jwt.decode(cookies.access_token) : false;
		event.locals.authenticated = !!jwtPayload;
		event.locals.user = { email: jwtPayload?.email };
		event.locals.access_token = jwtPayload;
	}

here we store the access_token in the event.locals for the request.

routes/api/auth

export async function post({ request }) {
	let body = await request.json();
	let session = body.session;

	let user = session.user;
	db.auth.setAuth(session.access_token);
        ...

and here we are explictly setting the auth sychronously before we make the call with the supabase client. Each call to the supabase client is asynchronous, so we should do this every time to maintain RLS

[gbailey4]

Being new to Sveltekit I'm having a hard time applying this to an application I'm building. Is there a repo out there I can refer to and see the full system in motion? I've copied the files from @eikaramba into a project I'm working on but it's not clear to me how to trigger logins (do I just use the supabase.auth.signIn() method?), or how to get the user object from the cookie on other pages (my session object is blank, could be importing it wrong or something).

Something as simple as an app just showing login and how to access the login info would be super helpful in getting going here.

[eikaramba]

@gbailey4 unfortunately i am not using supabase anymore but directus with sveltekit, thus i cannot help much anymore. but i can say that you can just use the login.js endpoint from #889 and make a post request from your login page to that endpoint. the endpoint is setting a httponly cookie (meaning the cookie is set by server in the header not by client in js)
which then is "read" by the hook.js file and then the token is stored in memory in the session object for access in the frontend. Does that make sense?

akiarostami's code is a little newer in such a way that the kit api has some breaking changes since then. if i had more time i would go over everything and update the code and push it, but i don't like to make promises i can't hold.

[wwall3r]

I don't have a lot of time to get into that this week. However, the oauth examples are certainly on my list for finishing this up. Thank you for helping out with the snippet!

…

On Tue, Mar 8, 2022 at 9:29 AM Liam Sanft ***@***.***> wrote: btw i had a quite interesting issue on safari on ios too. Just food for thoughts (i don't necessarly believe this is the issue, but maybe who knows) safari is not setting a 3rd party domain cookie if you come from a redirect. e.g. you want to use oauth and then the flow is like this mywebsite -> apple.com (for oauth) -> mywebsite (now setting cookie for mywebsite) in this case the cookie will not be set! in other browsers it works. Quite interesting, but there is an easy workaround. just let the page refresh itself again automatically function buildquery(query){ if(query && Array.from(query).length>0){ return "?"+query.toString()+"&refresh=true"; }else{ return "?refresh=true"; }} //in some endpoint first serve a blank page that refreshes itself again automaticallyexport async function get({ locals, request, url, params }) {let cookies = cookie.parse(request.headers.get("cookie") || "");if (!cookies.refresh_token) { if(!url.searchParams.get('refresh')){ return { status: 200, body: `<html><head> <meta http-equiv="refresh" content="0; url=${buildquery(url.searchParams)}"> </head></html>` }; } }//the actual code ...} This only happened to me when using "SameSite=Strict". If you use "SameSite=Lax", it should work in Safari. — Reply to this email directly, view it on GitHub <#5218 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACS3J7VZJDGBPLRBTRAPH3U65P3TANCNFSM5NCDZJJA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[robots4life]

So far I have done client side auth with Supabase and that works well. However I am new to SSR auth with SvelteKit and that seems fiendishly complicated so far.. 😉

a) @eikaramba Concerning the issue with the cookie this post might help that was raised in this SvelteKit issue.
b) @akiarostami Does the code posted here give a solid solution that someone new to SSR could take to learn from or are there things missing ?
c) @silentworks Given this it would be supa-nice to have an in depth tutorial on how to do SSR auth in a solid way with Supabase and SvelteKit. 👍

Just last night I happen to stumble across this treasure trove of content and hope to see an official way documented by Supabase using SvelteKit with SSR. Thank you all for your input here. 👍

[robots4life]

In the May 2022 edition of the Svelte Blog there is this article that does SvelteKit SSR Auth with Supabase.

https://svelte.dev/blog/whats-new-in-svelte-may-2022

SvelteKit JWT authentication tutorial by pilcrowOnPaper

[pilcrowonpaper]

Lol, I didn’t realize my blog was featured.

There are things that can be improved (I believe cookie based JWT are vulnerable to CSRF attack), but basics should be same. I think I should re write the article though.

[finnstrand]

After using @akiarostami s code I get this error when I try to log in. Anyone seen anything similar and/or know how to solve it?

node:internal/errors:464
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_INVALID_URL]: Invalid URL
    at new NodeError (node:internal/errors:371:5)
    at onParseError (node:internal/url:552:9)
    at new URL (node:internal/url:628:5)
    at new Request (file:///.../node_modules/@sveltejs/kit/dist/install-fetch.js:5907:16)
    at file:///.../node_modules/@sveltejs/kit/dist/install-fetch.js:6189:19
    at new Promise (<anonymous>)
    at fetch (file:///.../node_modules/@sveltejs/kit/dist/install-fetch.js:6187:9)
    at setServerSession (/src/lib/utils/auth.js:46:8)
    at Module.setAuthCookie (/src/lib/utils/auth.js:55:8)
    at Object.eval [as callback] (/src/routes/__layout.svelte:28:32) {
  input: '/api/auth.json',
  code: 'ERR_INVALID_URL'
}

setServerSession looks like this and routes/api/auth.js is also an exact copy of the one posted above.

const setServerSession = async (event, session) => {
	console.log('Setting Server Session >>>', event, session)
	await fetch('/api/auth.json', {
		method: 'POST',
		headers: new Headers({ 'Content-Type': 'application/json' }),
		credentials: 'same-origin',
		body: JSON.stringify({ event, session }),
	})
}

[finnstrand]

Thanks for the swift reply @akiarostami

There are two auth.js right? One in lib with the methods and one in API with the post and get endpoints?

[finnstrand]

Ok, I managed to solve that by changing to an absolute path http://localhost:3000/api/auth.json.

Then I ran into an error where I couldn't set $app/stores/session on the server so I changed it to a writable store.

And now when I log in the store is displaying fine in the console but on the page, it just flashes and then is empty. It's empty on client-side navigation and flashes again with the correct content every time I hit reload.

Did anyone experience something similar?

[MrVoshel]

Similar problem, changing to an absolute path does not work for me. Just to be sure, is it correct using the normal supabase signIn function to set the cookie? At the moment I'm using a button that on:click={logIn}

async function LogIn() {
        const { session, error } = await auth.signIn({ email, password })
        console.log("session is: " +session.user.id);
        if (error) {
            invalid = true;
            return {
                status: 302,
                redirect: '/',
            };
        }
        openLogin = invalid = false;
        return {
            status: 200,
            headers: {
                cookie: 'session=' +session.user.id +'Path=/; HttpOnly; SameSite=Strict; Expires=' +new Date(session.expires_at * 1000).toUTCString() +';',
            },
        }
    }

[akiarostami]

Honestly I haven't touched this code for a long while, and I haven't done anything with Supabase / SvelteKit since then. SvelteKit is still changing so I don't know if anything has changed in their API or not. But Supabase just published their new auth helpers. That might be a more reliable path if you're implementing an Auth for Supabase / SvelteKit.

This is the helper repo.

[MrVoshel]

@finnstrand I solved my issues by following this video and the follow up. That's the repo from the video, remember to use window.location.replace() and not goto() as the latter is a client side router and you'd have to manually refresh the page to see the changes. I didn't use supabase-auth-helpers because atm it seems like docs are nonexistent. Hope this can help.

[christopherreay]

One thing it is worth noting in the abstract, is that the supabase isomorphic client, and in fact, more broadly, browsers in general, do not have a clientside security model that behaves the ways that users have come to expect. Specifically, "sessions", by which we mean an instance of a browser, when the browser is closed the "session" ends, are not supported for client side Supabase. if you need database access, and you have your website go direct to supabase, you have two choices. Either you use in memory supabase client, in which case the client will sign out if you refresh the page, or you use persistent access, in which case the client will automatically remain signed in for the duration of your refresh token. Neither of these behaviours are expected by the end user, which means, in my case, I will not use the supabase client side data funnel for this reason. People are not talking about this. Its deeply important that end users understand the security model of their web applications. Where can I go to discuss this seriously with supabase and others? Any idea? Christopher Reay (they / them) Be prepared to have your predictions come true

…

On Fri, 3 Jun 2022 at 23:18, Ahmad Kiarostami ***@***.***> wrote: Honestly I haven't touched this code for a long while, and I haven't done anything with Supabase / SvelteKit since then. SvelteKit is still changing so I don't know if anything has changed in their API or not. But Supabase *just* published their new auth helpers. That might be a more reliable path if you're implementing an Auth for Supabase / SvelteKit. This is the helper repo <https://github.com/supabase-community/supabase-auth-helpers>. — Reply to this email directly, view it on GitHub <#5218 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB2PPRT6K7SLCDBROETFY3VNKABPANCNFSM5NCDZJJA> . You are receiving this because you commented.Message ID: ***@***.***>

[wwall3r]

Session cookies can be used to store the tokens, which would effectively log the user out on browser close, since neither the access nor refresh token would be available to be sent, even if they are still valid.

[christopherreay]

Right, but the cookies should be http only, at which point what do you do with them? You can use them for the server side access, but for client side access... how do you structure the system. I cant think of a way tytyt Christopher Reay (they / them) Be prepared to have your predictions come true

…

On Sat, 4 Jun 2022 at 16:39, wwall3r ***@***.***> wrote: Session cookies can be used to store the tokens, which would effectively log the user out on browser close, since neither the access nor refresh token would be available to be sent, even if they are still valid. — Reply to this email directly, view it on GitHub <#5218 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB2PPTQ3NK32V7WKMG2P2DVNN2DZANCNFSM5NCDZJJA> . You are receiving this because you commented.Message ID: ***@***.***>

[wwall3r]

You can remove the http-only restriction. That's not any different than storing it in local storage or some other spot accessible via JS. If you're using SvelteKit, page endpoints can keep most of your data access on the server side. However, if you want to do client side updates (or use the live web socket stuff), then you must have the supabase auth on the client.

[kbrgl]

By the way, in case you're deploying to Vercel, you can just use Vercel's serverless functions instead of SvelteKit endpoints. Might be the easiest solution in many cases!

[silasabbott]

Actually, SvelteKit endpoints and server-side logic is all automatically mapped to Vercel Serverless Functions when deployed

[ANorseDude]

Can you give example? Den lör 9 juli 2022 10:51Kabir Goel ***@***.***> skrev:

…

By the way, in case you're deploying to Vercel, you can just use Vercel's serverless functions instead of SvelteKit endpoints. Might be the easiest solution in many cases! — Reply to this email directly, view it on GitHub <#5218 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGUFGWI37TGBUDR36SQTSDVTE4QLANCNFSM5NCDZJJA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kbrgl]

https://vercel.com/docs/concepts/functions/serverless-functions

Unfortunately, I found that this approach isn't perfect either, since there's currently a bug with Vite + the Vercel CLI that causes the development server to crash after 30 seconds.

[evanwinter]

Dropping this here in case it helps anyone out: https://github.com/supabase-community/auth-helpers/tree/main/examples/sveltekit-email-password

There seem to be some rough edges in that helper but it's brand new so I expect it'll get those smoothed out soon