Auth cookies not being set after migrating to Flightcontrol/AWS

Hello!

I’m migrating my simple app from Vercel to Flightcontrol and am using the basic Flightcontrol setup with no customizations, and dbAuth

Once deployed, everything seems to work — except I can’t set my auth cookie.

I am on the latest RedwoodJS incorporating this code: Setup Deploy FlightControl Broke Web -> API Communication So I don’t think it’s the same issue.

I noticed that the API and Server are on different cloudfront urls, so for a second I thought it might be a CORS issue? But then I realized that my users were being created correctly in the database and returning 200 errors, so that might point to it not being CORS? I’m not sure.

I haven’t customized the dbAuth setup much at all, so there’s no weird other settings that should.

Open to any and all thoughts. I might just move to Render per this: Deployment Options for CI/CD noobs but I do like the idea of being able to “drop down” to AWS and use other services like S3 as needed.

Thank you!

Hey there!

I’m also using FlightControl, and I don’t know if this would be the same problem that you’re having but I ran into some CORS issues when I applied a custom domain to the web side and did not apply the same domain to the API side.

The solution was to give both the web side and the API side a subdomain on the same one, i.e. web.domain.com and api.domain.com.

Again, no idea if that will help you, but I spent a good while dealing with this problem so wanted to mention it. I hope you get it figured out!

1 Like

Thanks for you thoughts @ahoopes16! I’m going to try that.

I also noticed in the Flightcontrol changelog that NODE_ENV is no longer being set for new projects, but it looks like the flightcontrol.json template doesn’t have that in the environmental variables. That change occurred about two weeks ago, is this something you saw in the last two weeks also? And, what were the issues you were seeing?

Just trying to cross-reference with your experience to hopefully get to the bottom of it.

@max-scriptt I haven’t run into any issues with the NODE_ENV piece yet, and I do make deployments weekly.

When I didn’t have both the API and web sides on the same domain, my cookies would not be set whenever I tried to login. I remember being confused because the request technically looked “successful”, but then users still wouldn’t be able to log in. I also ran into some trouble with this on Safari due to the SameSite property not being set properly.

Here’s my cookie set up in api/src/functions/auth.ts which is working for all browsers in production currently.

...
// Specifies attributes on the cookie that dbAuth sets in order to remember
    // who is logged in. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies
    // There are some weird issues with Safari that need to be worked around with these settings.
    // See https://stackoverflow.com/a/70545461/14123656
    cookie: {
      HttpOnly: true,
      Path: '/',
      SameSite: 'Lax',
      Secure: process.env.NODE_ENV !== 'development',

      // If you need to allow other domains (besides the api side) access to
      // the dbAuth session cookie:
      Domain:
        process.env.NODE_ENV === 'development'
          ? 'localhost'
          : process.env.COOKIE_DOMAIN,
    },
...

Then I had to set the COOKIE_DOMAIN environment variable to the shared domain with no protocol, e.g. domain.com.

Alright, I’ve been fighting this for a while, and tried pretty much every configuration of this.

First off, my node_env hypothesis was not true. Setting that did not help me.

I cannot get it to work. Samesite ‘Lax’, ‘Strict’, ‘None’. ‘Secure’ as either true or false. Every variation of my domain and subdomain. I’ve even set the domain through an environment variable and.

Upside is that I’ve learned a lot about CORS and the redwood logger. Downside is that this does not work.

The only thing I can think of is that I don’t have a custom domain setup (I’m on cloudfront.net still) so perhaps that’s causing some weird config error? Doesn’t make a lot of not sense but I’m at a loss.

@ahoopes16 thank you especially for your thoughts and old posts. I’ve gone through everything you’ve written on this and the relevant pr, but nothing that got me there.

Here’s my full code if you or anyone else wants to take a look. At this point I’m probably just going to assume it’s an AWS thing and try out render to see if that’s the path of less resistance. I’ll poke the flightcontrol guys to see if they have any thoughts too.

  const authHandler = new DbAuthHandler(event, context, {
    cors: { origin: process.env.REDWOOD_WEB_URL, credentials: true },
    // Provide prisma db client
    db: db,

    // The name of the property you'd call on `db` to access your user table.
    // i.e. if your Prisma model is named `User` this value would be `user`, as in `db.user`
    authModelAccessor: 'user',

    // A map of what dbAuth calls a field to what your database calls it.
    // `id` is whatever column you use to uniquely identify a user (probably
    // something like `id` or `userId` or even `email`)
    authFields: {
      id: 'id',
      username: 'email',
      hashedPassword: 'hashedPassword',
      salt: 'salt',
      resetToken: 'resetToken',
      resetTokenExpiresAt: 'resetTokenExpiresAt',
    },

    // Specifies attributes on the cookie that dbAuth sets in order to remember
    // who is logged in. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies
    cookie: {
      HttpOnly: true,
      Path: '/',
      SameSite: 'Lax',
      Secure: process.env.NODE_ENV !== 'development',

      // If you need to allow other domains (besides the api side) access to
      // the dbAuth session cookie:
      Domain:
        process.env.NODE_ENV === 'development'
          ? 'localhost'
          : process.env.COOKIE_DOMAIN,
    },

And env vars in prod per my logging:

{"custom":{"cookieDomain":"cloudflare.net","nodeProcess":"production","origin":"https://[redacted].cloudfront.net"},"msg":"Cookie options"}

where origin is process.env.REDWOOD_WEB_URL and is not redacted in the actual log.

1 Like

Quick update — there’s a typo in my post above (‘cloudflare’ v ‘cloudfront’) but fixing that does not fix my issue unfortunately. I’ve also tried just hardcoding Domain: 'cloudfront.net' which I can confirm breaks local dev (so it’s doing something) but does not improve things on Flightcontrol.

@max-scriptt Man, I’m sorry it’s been such a fight. You know what though, I think I ran into that too now that I think about it. If I remember right, cloudfront.net is blacklisted as an eligible shared domain name, because otherwise anyone hosting anything on cloudfront without a custom domain would be open to cross-site scripting each other. You might have to set up custom domains for that to work. I can’t find my sources on that, though, so take my reasoning with a grain of salt.

I always had a custom domain for my web side, so I thought I just needed to bring the API side along with it, but I think keeping the default cloudfront.net domain might just break things for secure cookies. :confused:

I’ll give it a shot and report back! I guess that makes sense? I can’t find any sources on it either but it would be a logical security concern! Let’s see if it works.

1 Like

@ahoopes16 Adding a custom domain didn’t work, unfortunately! The Flightcontrol team was very helpful too but they couldn’t figure it out either (been chatting in their discord).

At this point I think I’m going to cut my losses and move on. Between this and an issue I’m having with prerender not giving me performance benefits, I just don’t think redwood is going to be an appropriate tech choice for this project.

Thank you very much for your thoughts and assistance. I’m glad you were able to make it work for your setup! Hopefully if others run into this issue they’ll see this thread and be able to get caught up on the context quickly.

1 Like

@max-scriptt Ahh man, I’m very sorry to hear that it didn’t end up working out for you. I wish you the best of luck in whatever tech stack you choose next!