@Nagasaki45 most welcome! Great to hear it worked
pshoukry
indatawetrust
snewcomer
Phoenix Core Team
ijunaidfarooq
I am on heroku with Phoenix app. and this didnt work for me. any solution?
config :edge_commander, EdgeCommanderWeb.Endpoint,
force_ssl: [hsts: true, host: nil]
0
outlog
ijunaidfarooq
It didnt work.. 
results are the same, nothing get force. both app. and https://app. working, any other clues?
0
outlog
“it works for me”
can you check with curl
eg
curl -s -D- http://myapp.herokuapp.com
should output a 301 to the https
and
curl -s -D- https://myapp.herokuapp.com | grep -i Strict
should output
Strict-Transport-Security: max-age=31536000
1
ijunaidfarooq
nikody
I stumbled upon a similar problem with a Phoenix application deployed in AWS Elastic Beanstalk with a load balancer and the force_ssl: [rewrite_on: [:x_forwarded_proto] setting fixed the too many redirects errors. However, as the Plug.SSL documentation mentions:
Since rewriting the scheme based on x-forwarded-proto can open up security vulnerabilities, only provide the option above if:
your app is behind a proxy
your proxy strips x-forwarded-proto headers from all incoming requests
your proxy sets the x-forwarded-proto and sends it to Plug
I wanted to ask to be sure, but are there any security vulnerabilities in this case with an AWS LB? The AWS Classic Load Balancer documentations says:
Elastic Load Balancing stores the protocol used between the client and the load balancer in the X-Forwarded-Proto request header and passes the header along to your server.
So I assume the third case from the Plug.SSL docs (your proxy sets the x-forwarded-proto and sends it to Plug) happens in this case, am I correct to assume that and that this setting should be fine from a security perspective here?
0