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

Force SSL (to protect passwords and personal info) #57

Open
daguar opened this Issue Jan 30, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@daguar

daguar commented Jan 30, 2015

I believe looking at the code and experimenting with packet capture against the demo site that sign-up and login info is being sent in the clear (ie, info including password is being sent across the wire unencrypted)? Is that right?

Ideally, the app it should force connections to HTTPS to avoid this. And it's easy enough to use force_ssl to do this. Okay to do that?

@monfresh

This comment has been minimized.

Member

monfresh commented Jan 30, 2015

+1 for SSL.

Note that you can enforce it across the entire app in production.rb, like this.

Note that this will work just fine out of the box on a regular Heroku deployment with a *.herokuapp.com domain name. However, a custom domain name will require you to obtain your own SSL certificate. I documented this in the Ohana API Wiki.

@johnthepink

This comment has been minimized.

johnthepink commented Feb 23, 2015

@daguar The downside to @monfresh's suggestion, config.force_ssl = true, is that it uses HTTP Strict Transport Security (HSTS), which tells the browser to only use HTTPS across the entire app, and Chrome caches that for a year. So, making that switch will make it really hard to go back if you ever need/want to serve over HTTP again.

Using the force_ssl class method does not use HSTS, which makes it easy to switch back and/or only serve parts of your app over HTTPS.

Either way I'd be happy to add it for you 😸

@monfresh

This comment has been minimized.

Member

monfresh commented Feb 24, 2015

Interesting. I did not know that! But how likely would it be for a site to go back to HTTP? And in what scenario would you only serve parts of a site over HTTPS? Is there some functionality that can only happen over HTTP? Are there any downsides to serving an entire site over HTTPS?

@johnthepink

This comment has been minimized.

johnthepink commented Feb 24, 2015

I agree with you. I'd push the whole site over HTTPS. I just ran in to that issue on a different project where they wanted to serve over HTTP but had used HSTS previously. They didn't have a good reason for wanting to do this. But, I thought I'd mention it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment