v3.1.0 Adding secure cookie support

New feature: marking all cookies as secure. Added by @jmera in #231. In the future, we'll probably add the ability to whitelist individual cookies that should not be marked secure. PRs welcome.

Internal refactoring: In #232, we changed the way dynamic CSP is handled internally. The biggest benefit is that highly dynamic policies (which can happen with multiple append/override calls per request) are handled better:

1. Only the CSP header cache is busted when using a dynamic policy. All other headers are preserved and don't need to be generated. Dynamic X-Frame-Options changes modify the cache directly.
2. Idempotency checks for policy modifications are deferred until the end of the request lifecycle and only happen once, instead of per append/override call. The idempotency check itself is fairly expensive itself.
3. CSP header string is produced at most once per request.

Handle "fetch directives" when appending to a policy config

Bug fix for handling policy merges where appending a non-default source value (report-uri, plugin-types, frame-ancestors, base-uri, and form-action) would be combined with the default-src value. Appending a directive that doesn't exist in the current policy combines the new value with default-src to mimic the actual behavior of the addition. However, this does not make sense for non-default-src values (a.k.a. "fetch directives") and can lead to unexpected behavior like a report-uri value of *. Previously, this config:

{
  default_src => %w(*)
}

When appending:

{
  report_uri => %w(https://report-uri.io/asdf)
}

Would result in default-src *; report-uri * which doesn't make any sense at all.

Bug fix release - frozen CSP configs can raise errors in some cases

Bug fix for handling CSP configs that supply a frozen hash. If a directive value is nil, then appending to a config with a frozen hash would cause an error since we're trying to modify a frozen hash. See #223.

Add upgrade-insecure-requests support

Adds upgrade-insecure-requests support for requests from Firefox and Chrome (and Opera). See the spec for details.

h/t @reedloden

Prepare for upcoming rails 5 changes related to filters

See #215

This should allow use of Rails 5 without deprecations from before_filter. before_filter is deprecated and will be removed in Rails 5.1.

This change is not applicable for the 3.x series.

3.x

secure_headers 3.0.0 is a near-complete, not-entirely-backward-compatible rewrite. Please see the upgrade guide for an in-depth explanation of the changes and the suggested upgrade path.

3.x rewrite release candidate

secure_headers 3.0 is a near-complete rewrite that is not entirely backwards compatible. See the upgrade guide for migrating between 2.x and 3.x: https://github.com/twitter/secureheaders/blob/master/upgrading-to-3-0.md

Remove noisy deprecation warning

See #203 and cfad0e5

Upon upgrading to secure_headers 2.5.0, I get a flood of these deprecations when running my tests:
[DEPRECATION] secure_header_options_for will not be supported in secure_headers

/cc @bquorning

2.x deprecation warning release

This release contains deprecation warnings for those wishing to upgrade to the 3.x series. With this release, fixing all deprecation warnings will make your configuration compatible when you decide to upgrade to the soon-to-be-released 3.x series (currently in pre-release stage).

No changes to functionality should be observed unless you were using procs as CSP config values.

Bug fix release

If you use the header_hash method for setting your headers in middleware and you opted out of a header (via setting the value to false), you would run into an exception as described in #193

     NoMethodError:
       undefined method `name' for nil:NilClass
     # ./lib/secure_headers.rb:63:in `block in header_hash'
     # ./lib/secure_headers.rb:54:in `each'
     # ./lib/secure_headers.rb:54:in `inject'
     # ./lib/secure_headers.rb:54:in `header_hash'