redwoodjs / redwood

The App Framework for Startups
https://redwoodjs.com
MIT License
17.25k stars 991 forks source link

[Bug?]: Cookie/auth issues for vercel deployment on versions v8 + #11641

Open jgal1 opened 3 weeks ago

jgal1 commented 3 weeks ago

What's not working?

I'm seeing issues in a production deployment to vercel after upgrading from v7.7.4 to v8.3.0. The issue only shows up when deployed to vercel, local development behaves as expected. The issue is with auth/cookies not being set after the POST request to /api/auth (which does get a 200 response), but does not have the setCookie header. The subsequent GET request to /api/auth?method=getToken also has a 200 response but does not return the logged in users id. This results in the user not being able to get passed the login/signup page. The behavior does not show up when developing locally. I have a git repository with the minimal changes needed for a repro.

v7.7.4:

v8.0.0:

v8.3.0:

Please let me know if you need any more information about my setup. The app is setup with a free supabase postgres instance (example format for env vars below), hosted on vercel with env vars set in the following format:

- SESSION_SECRET= secret obtained from running 'yarn rw g secret'

- DATABASE_URL=postgres://postgres.example:examplepw@aws-0-us-west-1.pooler.supabase.com:6543/postgres?sslmode=require&pgbouncer=true&connection_limit=1

- DIRECT_DATABASE_URL=postgres://postgres.example:examplepw@aws-0-us-west-1.pooler.supabase.com:5432/postgres?sslmode=require

- NODE_ENV=production

The codebase for the reproduction lives at https://github.com/jgal1/redwood-vercel . The v7.7.4 branch has the code which works for both local and vercel deployment, the v8.0.0 branch has the v8.0.0 code which does not work when deployed to vercel, and the main branch has the v8.3.0 version which also does not work when deployed to production.

To get a fresh repository for the minimal reproduction follow the below steps:

yarn create redwood-app redwood-vercel --typescript
cd redwood-vercel && yarn install
yarn rw setup ui tailwindcss
yarn rw setup auth dbAuth
yarn rw setup deploy vercel

The vercel deployment uses the standard redwood preset, and the only requirement on vercel is to set the environmental variables which are stated above.

This shouldn't make any difference for this issue but for my specific case, to connect to the supabase postgres instance the schema.prisma file needs the following edit (add directUrl) to the 'datasource' config:

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_DATABASE_URL")
}

For local development, the DATABASE_URL and DIRECT_DATABASE_URL should be the same and should have the following format:

Please let me know if there is anything I can do to help debug, for example any vercel permissions issues viewing the deployed domains, or vercel logs.

The following two links to another github issue and the community discussion could be related, as they have similar symptoms:

How do we reproduce the bug?

See reproduction steps and repository above

What's your environment? (If it applies)

No response

Are you interested in working on this?

jgal1 commented 2 weeks ago

@tobbe @cannikin can you help me debug this?

dthyresson commented 2 weeks ago

Hi @jgal1 I'll try to reproduce but I am curious if perhaps https://community.redwoodjs.com/t/app-hosted-with-flightcontrol-issue-logging-in-signing-up-auth-resetting-cookie/7364/23?u=dthyresson might help?

Perhaps CORS/credentials need to be set now for Vercel as well?

Might you be able to try this and see if helps?

Thanks!

jgal1 commented 1 week ago

@dthyresson I believe it has to be a change to something in redwood that caused this as it works on vercel with 7.7.4 but not 8.0.0 unless vercel is doing something different based on the version of redwood? The frontend and backend in the example repo serve from the same url, so I'm not even sure how to follow the instructions from the community link since there isn't a repro and in that case the person with the issue actually was serving the api and web side from different urls. Can you take a look?