You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched existing issues to ensure the feature has not already been requested
🚀 Feature Proposal
Introduction
When accessing insecure localhost (for ex. http://localhost:3000) from a remote hosted UI (for ex. https://sandbox.service) the natural secure configuration for the local Fastify cookie is:
Why httpOnly? We don't want to allow the SPA on sandbox.service to potentially read the cookie and forward it to some arbitrary server for security reasons
Why Same-site none? Obviously we are in cross-site waters
Why secure true when we are running the local server on HTTP? Because we have to to make same-site none working. Happily, for browsers, localhost is an exception and does not require us to serve use TLS:
Fastify does not send cookies secure cookies over HTTP, only when trustProxy is enabled to be insecure and an additional header is set:
x-forwarded-proto: https
Workaround
constapp=Fastify({trustProxy: true,});// Workaround: Allow to use sandbox with localhostapp.addHook('preHandler',asyncfunction(request){request.headers['x-forwarded-proto']='https';});app.addHook('onSend',asyncfunction(_,reply){reply.headers({'Access-Control-Allow-Private-Network': 'true',});});
Suggestion
We should look for a more straight-forward solution to allow working in dev mode for this scenario. I'm not sure what's the best way to solve this?
A flag on Fastify config? allowPrivateNetworkAccess: true?
Lifting the need for x-forwarded-proto to be https and trustProxy be enabled when checking if a cookie can be sent to the client in general or just for localhost
This seems correct. I don't think we should promote insecure defaults. However documenting how to solve this common case seems useful. Would you like to send a PR?
Prerequisites
🚀 Feature Proposal
Introduction
When accessing insecure localhost (for ex. http://localhost:3000) from a remote hosted UI (for ex. https://sandbox.service) the natural secure configuration for the local Fastify cookie is:
Why httpOnly? We don't want to allow the SPA on sandbox.service to potentially read the cookie and forward it to some arbitrary server for security reasons
Why Same-site none? Obviously we are in cross-site waters
Why secure true when we are running the local server on HTTP? Because we have to to make same-site none working. Happily, for browsers, localhost is an exception and does not require us to serve use TLS:
Browsers should officially allow that combination but there is two issues here in regards to Fastify Cookie:
Chrome stops it's support for that combination except for Private Network CORS Header https://www.chromium.org/updates/same-site/
Fastify does not send cookies secure cookies over HTTP, only when trustProxy is enabled to be insecure and an additional header is set:
Workaround
Suggestion
We should look for a more straight-forward solution to allow working in dev mode for this scenario. I'm not sure what's the best way to solve this?
Express has the same problem: expressjs/session#837
Motivation
No response
Example
No response
The text was updated successfully, but these errors were encountered: