Comment by justusw | Hacker News Reader

Comment by justusw | Hacker News Reader

Parent Full thread

Proving the absence of a 0 day for whatever your solution you are using is always going to be difficult. But dwelling in thoughts like this is close to crossing the border to FUD territory. And who says there isn't a 0 day for Firebase auth?

We can put our faith in systems that have been hardened over the years and are easy and reliable to implement. And email + hashed/salted password belongs to them. And by that, I specifically mean using a library that takes over the hash/salting part for you. For me, not rolling your own crypto not only means not implementing your own hash algorithm, but also staying off-the-shelf with the code that calls said cryptographic functions.

I also like to stay conservative with regards to session cookies vs. JWTs. One has been around for more than 2 decades, is well understood, and has some really solid cross-browser security measures behind it (HttpOnly, Secure Cookie, etc.)

I personally like using the Django contrib auth library for this purpose.

May I ask a related question? Have you found a good way to do session auth in Django with httpOnly _without_ having to hit the server and see if you get a 403 back? Because it’s httpOnly I cannot know client side if I have a session cookie until I try and fail once.

Usually people experience this when they're using a React frontend that's served from a CDN, while the backend is served from a separate service.

If that's the case, the pattern you're describing is pretty normal and not an inherent cause for concern.

If you really want to workaround it, you can do this:

First, host your backend and your frontend from the same origin, so the initial window navigation includes the httpOnly cookie (make sure your cookie is set to SameSite=Lax, NOT SameSite=Strict). Then, before the CDN serves your static content, run some middleware to ensure the httpOnly cookie is valid, and add some kind of marker to the page body to indicate they're signed in (or redirect away if they're signed out).

The not-so-trivial part is running middleware in front of the CDN, but that's possible with things like Cloudflare Workers, and these days it's built-in to Next.js for most hosts.

For this approach you'll also want to make sure you can check cookie validity quickly at the edge, or else you'll be slowing down your CDN a lot.

Honestly, I just send a request and see if I get a 403/401 or not. With DRF you get an additional "auth credentials required" error JSON object back, so you can just evaluate that client side. Since I use fetch for my current project, I just need to check the response.

Reply on news.ycombinator.com