Force_ssl 在 Rails 中做什么？

在之前的 有个问题中，我发现我应该设置 nginx ssl 终止并且不让 Rails 处理加密数据。

那为什么会有下面这些呢？

config.force_ssl = true

我在生产配置文件中看到这个被注释掉了。但是如果预期 nginx 将处理所有 ssl 的东西，这样我的 Rails 应用程序就不会处理加密的数据，那么 config.force_ssl = true会做什么呢？

如果我知道我将一直使用 nginx，我是否应该在生产中将其注释掉？

65827 次浏览
小开

It forces all communication with the server to be encrypted and use SSL, i.e. through HTTPS.

When you include it in a controller that controller will only accept HTTPS requests.

Helpful links:

  1. http://api.rubyonrails.org/classes/ActionController/ForceSSL/ClassMethods.html
  2. http://rubydoc.info/docs/rails/ActionController/ForceSSL
  3. http://railscasts.com/episodes/270-authentication-in-rails-3-1?view=comments
小开

This setting forces HTTPS by redirecting HTTP requests to their HTTPS counterparts. So a browser visiting http://domain.com/path will be redirected to https://domain.com/path.

Leaving the setting commented out would allow both protocols.

You still have to configure your web server to handle HTTPS requests.

小开

It doesn't just force your browser to redirect HTTP to HTTPS. It also sets your cookies to be marked "secure", and it enables HSTS, each of which are very good protections against SSL stripping.

Even though HTTPS protects your app at "https://example.com/yourapp" against MITM attacks, if someone gets between your client and your server they can rather easily get you to visit "http://example.com/yourapp". With neither of the above protections, your browser will happily send the session cookie to the person doing the MITM.

小开

Setting config.force_ssl includes ActionDispatch::SSL. The ActionDispatch::SSL docs describe the functionality as follows (emphases added for clarity):

See the includes here and the docs for ActionDispatch::SSL here.

DOCS

This middleware is added to the stack when config.force_ssl = true, and is passed the options set in config.ssl_options. It does three jobs to enforce secure HTTP requests:

  1. TLS redirect: Permanently redirects http:// requests to https:// with the same URL host, path, etc. Enabled by default. Set config.ssl_options to modify the destination URL (e.g. redirect: { host: "secure.widgets.com", port: 8080 }), or set redirect: false to disable this feature.

  2. Secure cookies: Sets the secure flag on cookies to tell browsers they mustn't be sent along with http:// requests. Enabled by default. Set config.ssl_options with secure_cookies: false to disable this feature.

  3. HTTP Strict Transport Security (HSTS): Tells the browser to remember this site as TLS-only and automatically redirect non-TLS requests. Enabled by default. Configure config.ssl_options with hsts: false to disable. Set config.ssl_options with hsts: { … } to configure HSTS:

    • expires: How long, in seconds, these settings will stick. Defaults to 180.days (recommended). The minimum required to qualify for browser preload lists is 18.weeks.
    • subdomains: Set to true to tell the browser to apply these settings to all subdomains. This protects your cookies from interception by a vulnerable site on a subdomain. Defaults to true.
    • preload: Advertise that this site may be included in browsers' preloaded HSTS lists. HSTS protects your site on every visit except the first visit since it hasn't seen your HSTS header yet. To close this gap, browser vendors include a baked-in list of HSTS-enabled sites. Go to https://hstspreload.appspot.com to submit your site for inclusion. To turn off HSTS, omitting the header is not enough. Browsers will remember the original HSTS directive until it expires. Instead, use the header to tell browsers to expire HSTS immediately. Setting hsts: false is a shortcut for hsts: { expires: 0 }.

Requests can opt-out of redirection with exclude:

config.ssl_options = { redirect: { exclude: -> request { request.path =~ /healthcheck/ } } }

提交答案