secure: false does not remove cookies secure -flag
See original GitHub issueExpected behavior
when secure: false
, cookies secure flag should be automatically removed
Actual behavior
secure flag is not removed
Setup
- http-proxy-middleware: 0.17.4
- other relevant modules: webpack-dev-server
proxy middleware configuration
proxy: {
'/': {
target: 'https://mydomain.com',
secure: false,
changeOrigin: true,
hostRewrite: true,
autoRewrite: true,
xfwd: true,
cookieDomainRewrite: '',
}
}
There is a workaround for this by removing the secure flag manually like
proxy: {
'/': {
target: 'https://mydomain.com',
secure: false,
changeOrigin: true,
hostRewrite: true,
autoRewrite: true,
xfwd: true,
cookieDomainRewrite: '',
onProxyRes: proxyResponse => {
if (proxyResponse.headers['set-cookie']) {
const cookies = proxyResponse.headers['set-cookie'].map(cookie =>
cookie.replace(/; secure/gi, '')
);
proxyResponse.headers['set-cookie'] = cookies;
}
}
}
},
but it takes time to figure out that the flag should be removed, and I expected secure:false to setup all this kind of stuff for me.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:15
- Comments:8 (3 by maintainers)
Top Results From Across the Web
TLS cookie without secure flag set
If the secure flag is not set, then the cookie will be transmitted in clear-text if the user visits any HTTP URLs within...
Read more >Secure Cookie Attribute
The purpose of the secure attribute is to prevent cookies from being observed by unauthorized parties due to the transmission of the cookie...
Read more >Any reason NOT to set all cookies to use httponly and secure
Yes, there are cases where you don't want HTTP ONLY or SECURE. ... When the httponly flag is not set on the cookie...
Read more >Securing cookies with httponly and secure flags [updated 2020]
When a secure flag is used, then the cookie will only be sent over HTTPS, which is HTTP over SSL/TLS.
Read more >The HttpOnly Flag – Protecting Cookies against XSS
The Secure flag is used to declare that the cookie may only be transmitted using a secure connection (SSL/HTTPS). If this cookie is...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
In my opinion… when I set changeOrigin: true, and I’m going from http://localhost:3000 to https://qa.api.com, it should just work…
But I had to dive deep into the http headers and eventually figured out the cookies weren’t being set - then I dived deep into cookies and figured it’s because the cookies have this secure; flag.
So it’s really an implementation detail - maybe there could be an option for patching the cookies - but I’m not sure what to call it -
ohBTW_patch_cookies: true
- it’s really just a messy thing that has to do with http/cookies that developers shouldn’t have to think about/be exposed to.At the end of the day I guess it’s as easy as just copy pasting these few lines to remove the secure flag: https://github.com/http-party/node-http-proxy/issues/1165#issuecomment-431025061
Don’t think it’s wise to modify the behaviour of
secure
, which is a configuration option of the http-proxy library.There is a thread for this issue: https://github.com/nodejitsu/node-http-proxy/issues/1165
imho, the ecosystem would benefit more if it is solved there.
I’m open for suggestions.