Skip to content
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

Removal of "secure" breaks "SameSite=None" #14

Closed
gavenkoa opened this issue Jan 9, 2024 · 4 comments
Closed

Removal of "secure" breaks "SameSite=None" #14

gavenkoa opened this issue Jan 9, 2024 · 4 comments

Comments

@gavenkoa
Copy link

gavenkoa commented Jan 9, 2024

The plugin has code:

/* On insecure connections, remove `secure` attribute from remote cookies */
const setCookies = remoteRes.headers['set-cookie']
if (!ctx.req.socket.encrypted && !lws.config.rewriteKeepSecureAttr && setCookies && setCookies.length) {
  const cookies = setCookies.map(c => util.removeCookieAttribute(c, 'secure'))
  remoteRes.headers['set-cookie'] = cookies
}

If secure attribute is removed but there is "SameSite=None" a browser rejects cookie, breaking all login pages. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie for exact error message in a browser DevTools:

Cookie "myCookie" rejected because it has the "SameSite=None" attribute but is missing the "secure" attribute.
This Set-Cookie was blocked because it had the "SameSite=None" attribute but did not have the "Secure" attribute, which is required in order to use "SameSite=None".

Consider removing SameSite=None together with secure. Other values of SameSite are safe without secure.

@75lb
Copy link
Member

75lb commented Jan 9, 2024

Have you tried removing SameSite=none along with secure and verified it works for you?

Also, just a reminder there is a flag you can set to override secure stripping:

  --rewrite.keep-secure-attr       When local-web-server is running in plain, insecure HTTP mode (not HTTPS or
                                   HTTP2), stripping the `secure` attribute from remote, rewrite-target cookies
                                   is the default behaviour. Set this flag to leave remote `secure` cookies
                                   untouched - this may prevent cookies functioning correctly when your server
                                   is plain HTTP.

@gavenkoa
Copy link
Author

I didn't remote SameSite=None, instead I changed the source to pass SameSite=Lax as a workaround.

As we proxy API to http://localhost:3000 for Next.js static app build, pointing to STAGE env for API served via https://..., the removal of secure attribute is a correct behavior.

Breaking thing is keeping SameSite=None, when secure is removed. SameSite=None cannot be without secure in modern browsers - the Set-Cookie ignored in this case. For local development with traditional Node.js http://localhost:3000 - both should be stripped.

@75lb
Copy link
Member

75lb commented Jul 25, 2024

The fix has landed in lws-rewrite v4.0.0, will post against once I've added it to local-web-server..

@75lb
Copy link
Member

75lb commented Aug 1, 2024

Fixed and released in local-web-server v5.4.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants