I’ve been asked to add a secure flag to a cookie which I believe is being created as a result of this plug:
# 1 day
We are using Redbird as our adapter for
Plug.Session but the cookie does not have a secure flag.
If I try adding something like:
secure: true to the above plug I will get an invalid CSRF token error from Phoenix when I try to log in.
Are you running your application over HTTPS? The
secure flag for cookies has the effect to allowing transmission the cookie only over HTTPS. If you are using HTTP, the cookie marked as
secure won’t be re-transmitted by the browser upon making a request, which could cause your CSRF token error.
Plug.Session should set
true by default when the connection is HTTPS, as documented here.
Yes in production it’s HTTPS, but the cookie is not flagged as secure (at least in the browser).
Your application may not be aware that requests are made over HTTPS. If TLS is terminated externally, in a load balancer or reverse proxy, Plug needs to be told to treat the request as HTTPS using a header. Plug.SSL can do that for you.
For Plug, see the Plug SSL guide for details. In Phoenix you’d typically use the
force_ssl Endpoint configuration rather than Plug.SSL directly (it accepts the same options).
Great point about the proxy and
Plug.SSL. Setting the options like
:rewrite_on properly and then letting
Plug.Session set cookie as secure on HTTPS by default is probably the best option if the app is behind a proxy.
Still, if I am not misunderstanding the docs, from the application point of view, when
secure: true is explicitly added to the
Plug.Session options, the
secure flag should be forced to
true on the cookie no matter if the connection is HTTP or HTTPS.
Some browsers (like Chrome) will ignore the
secure flag is
true but the protocol is not HTTPS, but if the production app is served over HTTPS this should not be the problem.
@travisf maybe you could inspect the response headers set by Phoenix, to determine if the app is even trying to set the cookie as secure or not. Can you see the
Set-Cookie header? Does it contain
Looking at the headers in Chrome, specifically
set-cookie for this header. This is the case in both dev and prod environments.
@voltone I haven’t gotten too far into Endpoint configuration, I was called away to some other things today but I will look into that and let you know how it goes.
I started down the path of setting HTTPs locally based on the Endpoint configuration, but I think that was a bit more overhead based on our current setup. We ended up just setting
secure to true in the production environment and not worrying about it locally (which I think the was the crux of my issue to begin with).