-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only pass session id cookie to api #65
Comments
FYI I'm pretty sure this is only something that can be configured from the frrontend |
but if it can be enforced by the backend somehow that would be kewl |
Cookies are intended to be issued by servers. They're a method by which a server can store data on the client. Local storage is how a client can store data on the client & not automatically sent it to the server (🔥). It's true that clients can create cookies, but it's not a great idea unless it's intended to communicate with the server somehow. Give a quick scan through the mozzilla page for it You'll see in auth/login the cookie is set by the server. This is where we'd want to look into adding attributes to it. Of course, maybe it's not even worth it as mentioned above. |
Right yes, but what I mean is that the server issues the auth cookie, but once it's in the client's browser, the server can't really force the client to not send the cookie for GET requests, but do send the cookie for other requests - or at least not that I know of. I think to prevent the client sending certain cookies, or any cookies for certain requests, this is something that must be done from inside the Fetch API |
See the same site attribute I linked to at the beginning of this PR :) Though actually, it seems that wasn't the exact attribute we'd care about, instead the path attribute is the one we'd care about |
Ahh, yeah, I've read about same site before and was like, this isn't gonna work for this case 🤣 Restricting to the path would definitely fix this, and that's something the backend can do |
Nice! |
We should look into only sending the session id cookie to the api endpoint.
Since our session tokens are reasonably sized (& intended to be private), it's a good idea to not go throwing them at every page & resource GET. There's no security or performance issue of course (latency is way slower than several bytes of data), but it's a good idea to only do what's necessary.
Unless of course, we have some need in the future for non-api pages to serve restricted content? (#54)
The text was updated successfully, but these errors were encountered: