I'm having some trouble with OTP auth:

await supabase.auth.signIn({email})

This triggers an email, and when the verification link is clicked, it redirects to http://localhost:5173/#access_token=[...]&expires_in=3600&refresh_token=[...]&token_type=bearer&type=magiclink AFAIK that Supabase -> GoTrue -> redirect flow should set browser cookies, but that's not happening and I'm not sure why

Hello @Aris! This thread has been automatically created from your message in #843999948717555735 a few seconds ago. We have already mentioned the @User so that they can see your message and help you as soon as possible! Want to unsubscribe from this thread? Right-click the thread in Discord (or use the ``...`` menu) and select "Leave Thread" to unsubscribe from future updates. Want to change the title? Use the ``/title`` command! We have solved your problem? Click the button below to archive it.

Please provide more information about what your code looks like

Sure!

<script lang="ts">
    import {provider} from "$lib/auth"
    async function submit() {
        const email = "temporarily-hardcoded@example.com"
        const res = await provider.signIn(
            {email}
            // temporarily removed
            // {
            //     shouldCreateUser: true,
            //     redirectTo: "/auth/otp-ok",
            // }
        )
        console.log("otp submit", res)
    }
</script>

<form on:submit|preventDefault={submit}>
    <div>
        <input
            type="email"
            id="email"
            name="email"
            autocomplete="email"
            placeholder="me@example.com"
            required
        />
    </div>
    <button type="submit">Continue with email</button>
</form>

Can you provide the code for the page it returns to when you click the email link?

It redirects to

/

because Supabase doesn't seem to support custom redirects for Magic links. So I'm only doing logging to debug this:

// hooks.ts

export const handle: Handle = async ({event, resolve}) => {
    const {
        locals,
        params,
        request: {method, headers},
        url: {pathname},
    } = event

    const cookies = cookie.parse(headers.get("cookie") ?? "")

    console.log(`server: handle ${method} ${pathname}`, locals, params, cookies)
    console.log(headers)

    const res = await resolve(event)
    return res

Looks like you are using SvelteKit, you wouldn't be able to parse the cookie as its a domain specific cookie. This cookie is stored on the supabase domain

Yes, I have. I may have missed the section that sets a cookie for me. That's basically what I'm trying to do here.

I don't see any part of this code where you are using the auth-helpers

I've had a look at the library, I'm not using it

In the case of the library its parsing a cookie that is set on its own domain, so the library saves that cookie itself

With how quickly they update, all versions of SvelteKit are old versions. 😛

Yeah still pre-1.0 so breaking changes happen

Checking now...I see in the /callback endpoint they check

request.json()

, if Supabase is POSTing that on the redirect then I believe that's what I need to parse

No Supabase isn't POSTing anything to the server, everything happens on the client. The second link I posted in the message above highlights that

From your code:

const expressStyleRequest = await toExpressRequest(request)
const { user } = await supabase.auth.api.getUserByCookie(expressStyleRequest)

export async function toExpressRequest(req, body = {}) {
    return {
        body,
        headers: { host: req.headers.get('host') },
        cookies: cookie.parse(req.headers.get('cookie') || '')
    }
}

As stated before that is old SvelteKit, it won't work with current version at all

Sure. I've reviewed those codebases in depth, so I think we're missing each other a bit. Here's what we've discussed: My code is trying to check a cookie that doesn't exist. On OTP signin, the flow is verify email -> Supabase -> (gotrue under the hood) -> redirect to http:/localhost:5173/#access_token=... with no cookie header That makes sense. What I don't understand is that all of the referenced code examples (auth-helpers, your project) seem to be checking that exact same cookie, and that works for them. If I used those libs myself, they would be running in the same context as my code. So: a) if they can see the cookie, I should be able to see the cookie directly b) if I can't see the cookie, neither should they and they should be broken as well c) the cookie header is a red herring and is just a fallback, they're setting the initial auth state via a different codepath and I need to do the same

a) they can't see the cookie you are thinking of, they are creating their own cookie on the server they are running on (in this case

localhost

)

Ah! That would indeed explain it. I thought

handleCallback

was passing through a cookie received from SB. Here's the meat of `/handlecallBack`:

export const handleCallback = (options: HandleCallbackOptions = {}) => {
    const handle: Handle = async ({ event, resolve }) => {
        const req = event.request;
        let res = await resolve(event);

        [...]

        const { event: bodyEvent, session } = await req.json();

        if (bodyEvent === 'SIGNED_IN') {
            if (!session) throw new Error('Auth session missing!');
            setCookies(
                new SvelteKitRequestAdapter(req),
                new SvelteKitResponseAdapter(res),
                [
                    session.access_token ? { key: 'access-token', value: session.access_token }: null,
                ]
            )
        }
    }
}

The function grabs the session from

req.json()

. I'm not sure how this reconciles with your earlier remark that: "No Supabase isn't POSTing anything to the server." ?

> The function grabs the session from req.json(). I'm not sure how this reconciles with your earlier remark that: "No Supabase isn't POSTing anything to the server." ? Correct Supabase is not POSTing anything to the server, my client side code is doing this https://github.com/supabase-community/auth-helpers/blob/main/packages/svelte/src/SupaAuthHelper.svelte#L58-L83

Huh! So we're ping ponging it: 1) click verify link in email 2) supabase (gotrue) 3) server

/

4) client

/

5) client triggers registered auth listener state change 6) client listener fetches

/callback

(passing in session data somehow, hopefully I can find this in the supabase-js.auth code) 7) server

/callback

sets cookie for my domain as passed by above 8) client (still at

/

) refreshes auth state from

/callback

response

Yep pretty much that

Thanks for all your help! It looks like step 6 parses the session from the URL hash on the client, which is enforced by the SvelteKit package's auth wrapper around the whole app slot. There's even a note: > // Forward session from client to server where it is set in a Cookie. > // NOTE: this will eventually be removed when the Cookie can be set differently. I think this can be implemented a bit more cleanly. Rough sketch: In global

__layout:load()

, do

if (browser) refreshAuth(url.hash)

, and put the machinery there (parse, set cookie/localStorage, clear hash, update Svelte

$session

store instead of firing event). Should eliminate the need for

/callback

and the application wrapper Svelte component AFAIC.

Test that out and see if it works for you, the hash is handled by the

supabase-js

library, so you will have to catch it before the library catches it and removes it form the url

I think it'll work. Pro: easier to work with other Svelte code that watches for $session changes. Con: may make using

supabase-js

a lot harder

Also remember

load

is going away in SvelteKit at some point in the future

I hadn't heard that, if they move to page endpoints only then hopefully they give us a client side hook equivalent / middleware

Yeah Rich mentioned it in his talk, one of the last hurdle right now is getting page endpoints working with __layouts

Yes, can still set a cookie there if needed for SSR.

That wouldn't be an issue with the

auth-helpers

, thats

gotrue-js

thing

Just discovered something - GoTrueClient does the majority of what I want automatically:

if (settings.detectSessionInUrl && isBrowser() && !!getParameterByName('access_token')) {...}

This is in the client constructor, which

supabase-js

automatically instantiates for you. So, if you create a client instance somewhere on the browser side like

__layout:onMount

, it will process

/#access_token=...

, saving it to localStorage (no cookie set) under

supabase.auth.token

The reason for the cookie is server side use of supabase, I should have made that clear earlier