First off thank you for the application, I am using it as a reference for a solution I am creating.

I am running into a problem where I am getting an error saying

[1] { message: 'JWT expired', code: 'PGRST301', details: null, hint: null }

when doing queries in my application. I am confused because the call to getAuthSession is returning a valid session but when get the supabase client

    const supabaseClient = supabase(authSession?.accessToken as string);

and make a database call, it errors out

I'll start working on migrating this stack to supabase-js v2. It's still a release candidate so it'll not be merged to master until it's stable 😉 I think it's possible to create a remix project from a stack's branch name, so, you'll be able to test this in advance.

Maybe some changes will happen on main to prepare for this upgrade.

I plan to :

• make a better readme
• clean some messy things like rewriting RLS and real-time examples, extracting components, etc...
• add some doc on how to delete what you don't want to start your new project

No release date, doing my best 😅

Hi again, not sure if I'm doing anything wrong but when I run the headless cypress test, the mocking doesn't seem to work and it calls my Supabase API. I can see the users and notes being created and cleaned up in my Supabase dashboard during the tests.

And since it called the actual api, test cases were failing and I had to add this check to wait for the api finishes and route changed to make it pass.

Steps to reproduce:

1. npx create-remix --template rphlmr/supa-fly-stack
2. Correct the .env file
3. npm run setup
4. npm run test:e2e:run

The refreshAccessToken function calls into supabase-js using

https://github.com/rphlmr/supa-fly-stack/blob/bd100e0754adae1922fab4ea6a3f412ea7bf1268/app/modules/auth/service.server.ts#L60-L63

(note access_token: "") However, inside supabase we hit the code path

/**
   * Sets the session data from the current session. If the current session is expired, setSession will take care of refreshing it to obtain a new session.
   * If the refresh token or access token in the current session is invalid, an error will be thrown.
   * @param currentSession The current session that minimally contains an access token and refresh token.
   */
  async setSession(currentSession: {
    access_token: string
    refresh_token: string
  }): Promise<AuthResponse> {
    try {
      if (!currentSession.access_token || !currentSession.refresh_token) {
        throw new AuthSessionMissingError()
      }

So the code always errors (file can be found at node_modules/.pnpm/@[email protected]/node_modules/@supabase/gotrue-js/src/GoTrueClient.ts lines 626 and following)

When debugging in vs code, breakpoints are shown in ./build/index.js and not in the original files. Is this expected / Is there a way to get full source map support?

Change what happens in oauth.callback and verifyAuthSession Linked to https://github.com/rphlmr/supa-fly-stack/issues/45 from @Benjamin-Dobell

What's new :

• oauth.callback action no more trust authSession it receives from the client
• oauth.callback (client side) only sends refresh_token found in onAuthStateChange
• oauth.callback action uses authSession returned by refreshAccessToken, called with the refresh_token received
• verifyAuthSession compares authSession user id and user id returned by getAuthAccountByAccessToken. It's only a last guard against session cookie secret leak

Hello there,

Someone ask this and maybe it's a good idea to not scatter people with multiple ways to handle auth in Remix with Supabase.

Maybe I should rewrite auth with https://supabase.com/docs/guides/auth/auth-helpers/remix.

I don't want to replace Prisma 🥶 but only the Auth part.

After that, it should be a breeze to replace Prisma with Supabase to query your database if this It what you need for your project.

I'll probably do some abstraction to keep helpers like requireAuthSession and keep things simple to use in protected loaders/actions.

Is It something you are interested in or do you prefer to be able to modify what you want with the actual auth implementation?

Just noticed CC BY-NC-SA 4.0 tacked on down the bottom of the README. A copyleft non-commercial license seems highly unusual for a template, however it's your project so absolutely at your discretion.

That said, could you please add a LICENSE file so that Github prominently displays the license?

There's a (minor?) security issue and a few oddities I noticed with the way auth is being handled.

OAuth Callback Auth Session Vulnerability

The action in oauth.callback.tsx accepts a form data encoded AuthSession from the client and trusts its contents. Consequently, you can submit a real email with a fake access token etc. and side effects will be triggered.

If an account exists for the email, the server will commit (sign) the bogus auth session data and store it in a cookie used for future requests. If a user doesn't exist for the email, one will be created and we'll also end up with bogus auth session cookie as above.

Whilst not great, this is fairly safe at present since requireAuthSession() is being used on endpoints, and it calls through to verifyAuthSession(), and consequently it'll catch the bad access token. That does assume APIs are calling through to verifyAuthSession(). However, that leads into another concern, which is admittedly more of a query.

Why create our own auth session cookie at all?

The Supabase JS library is already creating its own sb-access-token cookie which contains all the same data. The main difference is it's created/verifiable with the Supabase instance's JWT secret key. Thus, in order to validate the token we need do one of:

1. Perform a round trip to Supabase as verifyAuthSession() does.
2. Grab the JWT secret from the Supabase dashboard and add it as a server-only environment variable. Then we can then validate the JWTs directly on our server without the round trip.

I guess the advantage of our own session cookie is that we can validate it ourselves on the server without needing to grab the Supabase JWT secret and save on a round trip i.e. we can trust its contents. However, we're not doing that, we are performing round trips via requireAuthSession(). Just as well because of the aforementioned OAuth Callback vulnerability. However, it does make the contents of the cookie redundant, since we can't trust the contents without verifying the access token, and in doing so, we're fetching the same data that's found in the cookie anyway.

Email Addresses as Unique Keys

Email addresses are being used as unique keys. This stack doesn't claim to support oauth beyond magic links, so it's fine. However, this approach becomes problematic when integrating social OAuth - which is what I was doing when I discovered all the above. Basically, users can change the email address associated with their OAuth provider. Say for example someone signs up via Github social auth whilst their email is [email protected]. If they proceed to change their primary email on Github to [email protected], when that user returns to a site built on this stack and attempts to authenticate, no account will be found.

Again, the stack doesn't claim to support social auth, so it's by no means a bug. However, that part of the auth design could probably be shored up a bit to make it more robust/extensible.

Thank you

After me ranting about problems, just wanted to say thanks for all the hard work! Despite the above, this is my first time using Remix and this repo is, at the very least, super informative.

Just a heads up I updated prisma and @prisma/client to 3.12.0 and began getting a

An error occured while running the seed command:
Error: Command was killed with SIGKILL (Forced termination): ts-node --require tsconfig-paths/register prisma/seed.ts

I downgraded back to 3.11.1 and everything worked as expected.

Major changes :

• Supabase JS SDK V2 😇
• Folder structure
  • Previous module's mutations/queries are now in a service.server (collocate all the module's service in one place)
• Auth session is reworked to align with folder structure changes
• requireAuthSession no longer call Supabase Auth API by default to verify user access token (it's still safe, we signed our cookie)
  • requireAuthSession takes a new optional param called verify (boolean) to work as before 😉
• No more needing to start a shadow database to create a Prisma migration (I don't know why maybe it's thanks to Supabase). It results in a huge time saving!

Add Supabase Provider to use Supabase client (with RLS support) in the browser. Add a /rls route example to illustrate. Add /refresh-session route to enable session refresh (triggered by the Provider on expires). Add doc in a code comment to explain how It works. Add a migration to create a RLS table, for demo purposes. Add a type Database to have typing completion (It's only to illustrate how it works with supabase cli)