App hosted with Flightcontrol, issue logging in/signing up - auth resetting cookie

[Bennettbishop1]

Hi all!

I’ve deployed my redwood app via flightcontrol and am running into an issue logging in/signing up. When logging in or signing up, /auth is successfully called, the session cookie is set, and a (user) id is returned. However, right after, /auth?method=getToken is called, it doesn’t have a payload or response, and the cookie is deleted. This is preventing me from getting past the sign up/log in page. API is deployed to api.DOMAIN.com and web is deployed to web.DOMAIN.com.

I’ve been troubleshooting for a bit and it is not a CORS issue, also domains are verified with correct CNAME records propagated in DNS.

Anyone have any idea how to fix this? Thanks in advance for your help.

[dthyresson]

Hi @Bennettbishop1 I’ll ask the team and also let Flightcontrol know about this issue to see how might resolve.

Just to confirm: do you have all the necessary envars setup including the session secret?

[dthyresson]

@Bennettbishop1 FC said they were able to chat with you to help diagnose (many thanks to the Flightcontrol team!) but no luck yet.

Could you share a bit more about your environment- redwood version and also any toml config.

Do you see auth working in local dev and just not when deployed?

[rob]

Hello! I don’t see Secure as part of the cookie string, but the site is HTTPS…this may cause the browser to not send it up in the getToken request, and when there’s no cookie the backend replies with a “logout” response, which tells the browser to remove the cookie.

What’s your cookie config look like in api/src/functions/auth.ts? Is there some logic on the Secure property which is causing it not to be set?

[Bennettbishop1]

Thanks for reaching out! I’ve tried a few different cookie configs, this being the most recent. If you’d like I can share my entire authHandlerFunction. Thanks.

[Bennettbishop1]

Hi! Yes I’ve got the session secret and other envars set up in the flightcontrol dashboard.

[rob]

There you go, try setting that to Secure: true and see if it works in prod!

You’ll probably need to change it back in dev, or put a check in there to not set it secure in development environments (Safari doesn’t like sending a Secure cookie when it’s http://localhost) Our config out of the box looks like:

Secure: process.env.NODE_ENV !== 'development'

Which handles the Safari case (and works with the other browsers as well).

[Bennettbishop1]

Hi @dthyresson, thanks for your help. Im currently using version 6.4.1. Also that’s correct, auth works in local dev but just isn’t working in my deployed version. My toml config is just the default (screenshot below).

[Bennettbishop1]

Hi Rob. So, I’ve changed the cookie config and pushed it to prod, and unfortunately the same issue is arising. I do see ‘secure’ in the cookie string, however I still cannot get past the signup/login page. I’ve attached screenshots of the /auth as well as /auth?method=getToken. Thanks again for the help.

[rob]

Hmm, I thought for sure that would fix it! Can you take a screenshot of the request headers for the getToken request? I want to see if the browser is even sending the cookie back up to the server. If it is, then there’s a problem decrypting the cookie on the server side. If not, then something must still be off about the cookie and so the browser thinks it shouldn’t send it on subsequent requests.

[rob]

I just signed up to see if I could see the same behavior and sure enough I’m seeing the same thing! I can see that the cookie is NOT being sent up in the getToken request, which means something about it the browser doesn’t like. I’m going to do some more investigation…

[rob]

There’s something else I want to try, but in the meantime here’s what ChatGPT says are possible reasons why the browser wouldn’t send up that exact cookie…any of these sounds like something you have configured?

---

A browser may choose not to send the provided cookie to the server in the following circumstances:

Non-Secure Context: - The Secure attribute indicates that the cookie should only be sent over HTTPS. If the request is made over HTTP, the cookie will not be sent.

Mismatch in Path: - The Path attribute specifies that the cookie should only be sent for requests that include the specified path (/ in this case). If a request is made to a path that doesn’t match, the cookie won’t be sent.

Cross-Site Requests and Same-Site Policy: - The SameSite=None attribute indicates that the cookie should be sent with cross-site requests. However, some browsers may impose additional restrictions or may not fully support SameSite=None, especially older browsers.

Cookie Expiry: - Although the specified expiration date is far in the future (2034), if the browser’s system clock is incorrect or set to a date beyond the cookie’s expiration, the cookie will be considered expired and won’t be sent.

JavaScript Access: - The HttpOnly attribute disallows JavaScript from accessing the cookie. Though this doesn’t affect the sending of the cookie in an HTTP request, it ensures that the cookie is protected against XSS attacks.

Browser-Specific Limits: - Browsers have limitations on the size and number of cookies that can be stored. If these limits are exceeded, some cookies may be discarded.

Privacy Measures and Extensions: - Privacy-focused browser configurations, user settings, or browser extensions may prevent certain cookies from being sent.

Request is a Subresource and the User is Blocking Cookies: - If the request is for a subresource (like an image, iframe, or script), and the user has a setting or a privacy tool active that blocks cookies for such requests, the cookie won’t be sent.

Third-Party Cookies Blocking: - If the request is a third-party request and the browser (or user settings) blocks third-party cookies, then the cookie won’t be sent even with SameSite=None.

User-Initiated Cookie Clearing: - If the user clears cookies manually or uses a setting that automatically clears cookies upon closing the browser, the cookie will not be sent in subsequent requests.

[Bennettbishop1]

Thanks for taking a look! Assuming you don’t need those request header screenshots anymore as you can duplicate the problem. Let me know if you need anything more, and thanks again.

[Bennettbishop1]

Honestly no! Using all default cookie settings besides those we have discussed.

[rob]

Here’s something interesting… so if you go to Application > Cookies in Chrome’s Web Inspector you’ll sometimes see a little warning icon next to a cookie if something about it is weird and the browser won’t send on subsequent requests. Right now it’s getting removed too quickly and it never shows up there.

So, I tried blocking the request to auth?method=getToken so that the cookie would be set but not removed. However, when I did this, the cookie still doesn’t show in the Application > Cookies view. I did a test on a local running app and that does behave the way I’d expect: I block the getToken request and then the cookie remains in the browers and is viewable:

So something else is happening where the browser doesn’t even to want to save the cookie. Off the top of my head it seems like a CORS thing, but you’re sure that’s all configured properly for authentication? There’s a separate config for GraphQL as well: Cross-Origin Resource Sharing | RedwoodJS Docs It’s been a while since I worried about CORS stuff so I can’t immediately remember what the proper headers should be…

[rob]

There’s a commented section in the auth config about adding the Domain attribute, I didn’t see that in your screenshot above…do you have that set to your top-level brainsink.xyz domain?

[Bennettbishop1]

Hi @rob! I went ahead and added the domain attribute as described above. So far I am still running into the same issue.

[jamesj]

I’ll go out on a limb because I’ve seen something similar with my project, because I do some rather out of the ordinary stuff in my layouts and routes. Do you have any special setup for your Routes.tsx and how you handle layouts? What I mean is, can you reproduce this issue with a minimal deploy where you have just dbAuth and the login/sign up pages set up?

[rob]

Hmmm yeah I can see it coming through with the cookie when I try to log in…well, I’m running out of ideas!

Can we double check your CORS config?

• What’s your createGraphQLHandler() function in api/src/functions/graphql.tx look like?
• The cors property of your authHandler config in api/src/functions/auth.ts?
• The props passed to RedwoodApolloProvider in web/src/App.ts?
• The dbAuthClient initialization in web/src/auth.ts?

You said that everything works in local dev, correct? Which is all going to a single domain, localhost. You can simulate your multi-host production setup in development, have you tried that? This section of the docs details how: Cross-Origin Resource Sharing | RedwoodJS Docs

If it also doesn’t work locally then it definitely seems like it would be a CORS issue.

[rob]

Also: looks like you’re going through CloudFront, and we’re sure that’s not messing the the request/response at all?