dbAuth Works in Chrome, but not Safari?

Get Help and Help Others
1

I just finished the tutorial, and I’m very excited about potentially using Redwood on a potential new project. I think it is exactly what we are looking for!

While doing the tutorial (using Safari) the login page wouldn’t redirect to the home page on a successful login. I looked through all the code and couldn’t find any reason why it didn’t work. I decided to try it with Chrome it works perfectly.

I’m assuming this is a local setting on how cookies are handled, but after scouring this message board and many attempts at google, I can’t find anything that addresses this. Any suggestions?

2

Was that Safari on iOS or on Mac OS ?

3

It’s on MacOS (Ventura 13.0)
Safari Version 16.1.

4

I had the same problem with when I upgraded a project to RW 3.6 .

It definitely was a local setting on Safari. Chrome worked, Safari didn’t

Sorry, I don’t remember what I did exactly to correct it. But I believe I just went in and manually deleted the local storage for the app.

5

Thanks raj,
I deleted the localStorage on Safari (using the Safari->Settings->Privacy->WebSite Data) and I deleted everything for localhost. Still didn’t work. I did verify that localStorage was created for whatever that is worth.

I also added added localStorage.clear() in the App.js to see what effect that would have. Safari still didn’t work. Interestingly, it had no effect on Chrome either. I opened chrome, logged in, killed the browser, and went back to the website and I was still logged in. I think that tells me localStorage.clear() really doesn’t do anything, or doesn’t do what I thought it would. I did use the Chrome tools, deleted the localhost data and refreshed the browser and I was logged out, which I expected.

So I’m sort of at a loss here.

6

Were you actually signed in, and just didn’t redirect to the homepage, or could you not sign in at all?

Is there any output in the web console in Safari, showing a warning or error?

Were you accessing the site via localhost or 127.0.0.1?

7

Hi rob,
I think it’s actually logging in, because I get the welcome toast and it just doesn’t redirect. In the console window I get {id:1} which I believe is what it should be. Just to see what would happen, I intentionally put in a wrong password and in the console I got {error: "Incorrect password for admin@admin.com}

I’m using http://localhost:8910. I just tried http://127.0.0.1:8910 in Safari (and chrome) and on both I wasn’t able to connect. The etc/hosts file does map localhost to 127.0.0.1.

8

Well, you’ll get the Welcome message if the server says you’re logged in, but if the cookie doesn’t get set you’re not actually logged in. Can you browse to any other pages that give an indication if you’re logged in or not (like showing the logged in user’s email at the upper right)? Or try going to any pages that are protected by a <Private> route and see if get access or not?

My guess is that the cookie isn’t being set. Chrome has some exceptions for stuff like Secure cookies when accessed by localhost, but Safari doesn’t in some cases. Take a look at your cookie config, and try setting Secure: false Here’s the doc: Self-hosted Authentication (dbAuth) | RedwoodJS Docs

9

That was it!

I changed the cookie.Secure setting in api/src/functions/auth.js and it solved the problem.

You guys have built a very nice framework with an excellent tutorial and easy to follow documentation!

2 Likes
10

Hi there!

I’m currently building an application with RedwoodJS and was running into the same problem described here. It does look like setting the cookie’s Secure setting to false makes it work in Safari, but I’m also experiencing this problem where it’s deployed in production. Do I have to set it to false in all environments, and if so, what are the security ramifications of this?

Thanks!

11

In case anyone else comes across this, the problem I was running into was because I had it deployed to Cloudfront using Flightcontrol. The Domain setting on the cookies gets a little weird with Cloudfront if you aren’t using custom domains. So here’s the settings I ended up going with in order to make the cookies work with all browsers when deployed to AWS:

  • Add custom domains using subdomains of the same root to both the web side (web.example.com) and the API side (api.example.com)
  • Add an environment variable called COOKIE_DOMAIN that contains the root of your custom domain (example.com)
  • Change your cookie settings inside of api/src/functions/auth.ts to match the following:
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,
    }
12

In addition to the above, I also needed to do the last 2 items noted here and here. The latter code change seems out of date, and I instead needed to change web/src/auth.ts to:

const dbAuthClient = createDbAuthClient({
  fetchConfig: { credentials: 'include' },
})