Changelog History
Page 6
-
v2.5.1 Changes
February 16, 2016๐ See https://github.com/twitter/secureheaders/issues/203 and https://github.com/twitter/secureheaders/commit/cfad0e52285353b88e46fe384e7cd60bf2a01735
โฌ๏ธ >> 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
-
v2.5.0 Changes
January 06, 2016๐ 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.
-
v2.4.4 Changes
December 03, 2015๐ป If you use the
header_hash
method for setting your headers in middleware and you opted out of a header (via setting the value tofalse
), you would run into an exception as described in https://github.com/twitter/secureheaders/pull/193NoMethodError: 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'
-
v2.4.3 Changes
October 23, 2015@igrep reported an anti-patter in use regarding UserAgentParser. This caused UserAgentParser to reload it's entire configuration set twice* per request. Moving this to a cached constant prevents the constant reinstantiation and will improve performance.
-
v2.4.2 Changes
October 20, 2015๐ A nasty regression meant that many CSP configuration values were "reset" after the first request, one of these being the "enforce" flag. See https://github.com/twitter/secureheaders/pull/184 for the full list of fields that were affected. Thanks to @spdawson for reporting this https://github.com/twitter/secureheaders/issues/183
-
v2.4.1 Changes
October 14, 2015๐ This release may change the output of headers based on per browser support. Unsupported directives will be omitted based on the user agent per request. See https://github.com/twitter/secureheaders/pull/179
๐ p.s. this will likely be the last non-bugfix release for the 2.x line. 3.x will be a major change. Sneak preview: https://github.com/twitter/secureheaders/pull/181
-
v2.4.0 Changes
October 01, 2015โก๏ธ If you leveraged
secure_headers
automatic filling of empty directives, the header value will change but it should not affect how the browser applies the policy. The content of CSP reports may change if you do not update your policy.before
config.csp = { :default_src => "'self'" }
0๏ธโฃ would produce
default-src 'self'; connect-src 'self'; frame-src 'self' ... etc.
after
config.csp = { :default_src => "'self'" }
0๏ธโฃ will produce
default-src 'self'
0๏ธโฃ The reason for this is that a
default-src
violation was basically impossible to handle. Chrome sends aneffective-directive
which helps indicate what kind of violation occurred even if it fell back todefault-src
. This is part of the CSP Level 2 spec so hopefully other browsers will implement this soon.โช Workaround
0๏ธโฃ Just set the values yourself, but really a
default-src
of anything other than'none'
implies the policy can be tightened dramatically. "ZOMG don't you work for github and doesn't github send adefault-src
of*
???" Yes, this is true. I disagree with this but at the same time, github defines every single known directive that a browser supports sodefault-src
will only apply if a new directive is introduced, and we'd rather fail open. For now.config.csp = { :default_src => "'self'", :connect_src => "'self'", :frame_src => "'self'" ... etc. }
๐ Besides, relying on
default-src
is often not what you want and encourages an overly permissive policy. I've seen it. Seriously.default-src 'unsafe-inline' 'unsafe-eval' https: http:;
That's terrible. -
v2.3.0 Changes
September 30, 2015๐ See https://github.com/twitter/secureheaders/issues/167 and https://github.com/twitter/secureheaders/pull/168
๐ tl;dr is that there is a class method
SecureHeaders::header_hash
that will return a hash of header name => value pairs useful for merging with the rack header hash in middleware. -
v2.2.4 Changes
August 26, 2015As discussed in https://github.com/twitter/secureheaders/issues/154
-
v2.2.3 Changes
August 14, 2015