roda 3.82.0 → 3.84.0

data/doc/release_notes/3.69.0.txt

@@ -1,33 +0,0 @@
-= New Feature
-
-* The symbol_matcher method in the symbol_matchers plugin now
-  supports a block to allow for type conversion of matched
-  segments:
-
-    symbol_matcher(:date, /(\d\d\d\d)-(\d\d)-(\d\d)/) do |y, m, d|
-      [Date.new(y.to_i, m.to_i, d.to_i)]
-    end
-  
-    route do |r|
-      r.on :date do |date|
-        # date is an instance of Date
-      end
-    end
-
-  As shown above, the block should return an array of objects to yield
-  to the match block.
- 
-  If you have a segment match the passed regexp, but decide during block
-  processing that you do not want to treat it as a match, you can have the
-  block return nil or false.  This is useful if you want to make sure you
-  are using valid data:
-  
-    symbol_matcher(:date, /(\d\d\d\d)-(\d\d)-(\d\d)/) do |y, m, d|
-      y = y.to_i
-      m = m.to_i
-      d = d.to_i
-      [Date.new(y, m, d)] if Date.valid_date?(y, m, d)
-    end
-  
-  When providing a block when using the symbol_matchers method, that
-  symbol may not work with the params_capturing plugin.

data/doc/release_notes/3.7.0.txt

@@ -1,123 +0,0 @@
-= New Features
-
-* A content_security_policy plugin has been added for setting up an
-  appropriate Content-Security-Policy header.  To configure the
-  default policy, load the plugin with a block:
-
-    plugin :content_security_policy do |csp|
-      csp.default_src :none
-      csp.img_src :self
-      csp.style_src :self, 'fonts.googleapis.com'
-      csp.script_src :self
-      csp.font_src :self, 'fonts.gstatic.com'
-      csp.form_action :self
-      csp.base_uri :none
-      csp.frame_ancestors :none
-      csp.block_all_mixed_content
-    end
-
-  It's recommended that use use a default_src of :none at the top
-  of the policy, then explicitly change other settings (e.g. img_src)
-  when you want to allow content.
-
-  Anywhere in the routing tree, you can use the content_security_policy
-  method to override the default policy.  You can pass this method a
-  block:
-
-    r.get 'foo' do
-      content_security_policy do |csp|
-        csp.object_src :self
-        csp.add_style_src 'bar.com'
-      end
-      # ...
-    end
-
-  Or just call a method on it:
-
-    r.get 'foo' do
-      content_security_policy.script_src :self, 'example.com', [:nonce, 'foobarbaz']
-      # ...
-    end
-
-  The following methods exist for configuring the content security policy, they set
-  the appropriate directive, with the underscores replaced by a dash.
-  
-  * base_uri
-  * child_src
-  * connect_src
-  * default_src
-  * font_src
-  * form_action
-  * frame_ancestors
-  * frame_src
-  * img_src
-  * manifest_src
-  * media_src
-  * object_src
-  * plugin_types
-  * report_uri
-  * require_sri_for
-  * sandbox
-  * script_src
-  * style_src
-  * worker_src
-
-  All of these methods support any number of arguments, and each argument
-  should be one of the following types:
-  
-  String :: used verbatim
-  Symbol :: Substitutes underscore with dash and surrounds with single
-            quotes
-  Array :: only accepts 2 element arrays, joins elements with a dash
-           and surrounds them with single quotes
- 
-  Example:
-  
-    content_security_policy.script_src :self, :unsafe_eval,
-      'example.com', [:nonce, 'foobarbaz']
-    # script-src 'self' 'unsafe-eval' example.com 'nonce-foobarbaz'; 
-   
-  When calling a method with no arguments, the setting is removed from
-  the policy instead of being left empty, since all of these setting
-  require at least one value.  Likewise, if the policy does not have
-  any settings, the header will not be added.
-
-  Calling the method overrides any previous setting.  Each of the
-  methods has a add_* method (e.g. add_script_src) for appending to the
-  current setting, and a get_* method (e.g. get_script_src) for
-  retrieving the current value of the setting, or nil if it is not
-  defined.
-
-    content_security_policy.script_src :self, :unsafe_eval
-    # script-src 'self' 'unsafe-eval'; 
-    content_security_policy.add_script_src 'example.com', [:nonce, 'foobarbaz']
-    # script-src 'self' 'unsafe-eval' example.com 'nonce-foobarbaz'; 
-  
-    content_security_policy.get_script_src 'example.com', [:nonce, 'foobarbaz']
-    # => [:self, :unsafe_eval, 'example.com', [:nonce, 'foobarbaz']]
-
-  The clear method can be used to remove all settings from the policy.
-  
-  The following methods to set boolean directives are also defined:
- 
-  * block_all_mixed_content
-  * upgrade_insecure_requests
- 
-  Calling these methods will turn on the related setting.  To turn the
-  setting off again, you can call them with a false argument (e.g.
-  block_all_mixed_content(false)).  Each method also an *? method
-  (e.g. block_all_mixed_content?) for returning whether the setting is
-  currently enabled.
-  
-  Likewise there is also a report_only method for turning on report
-  only mode (the default is enforcement mode), or turning off report
-  only mode if a false argument is given.  Also, there is a
-  report_only? method for returning whether report only mode is
-  enabled. In report only mode, the Content-Security-Policy-Report-Only
-  header is used.
-
-= Other Improvements
-
-* The response_request plugin now integrates with the error_handler and
-  class_level_routing plugins.  Those plugins now reinitialize the
-  current response object instead of creating a new response object.

data/doc/release_notes/3.70.0.txt

@@ -1,19 +0,0 @@
-= New Features
-
-* A plain_hash_response_headers plugin has been added.  On Rack 3,
-  this changes Roda to use a plain hash for response headers (as it
-  does on Rack 2), instead of using Rack::Headers (the default on
-  Rack 3).  For a minimal app, using this plugin can almost double
-  the performance on Rack 3.  Before using this plugin, you should
-  make sure that all response headers set explictly in your
-  application are already lower-case.
-
-= Improvements
-
-* Roda now natively uses lower-case for all response headers set
-  implicitly when using Rack 3.  Previously, Roda used mixed-case
-  response headers and had Rack::Headers handle the conversion to
-  lower-case (Rack 3 requires lower-case response headers). Note
-  that Rack::Headers is still used for response headers by default
-  on Rack 3, as applications may not have converted to using
-  lower-case response headers.

data/doc/release_notes/3.71.0.txt

@@ -1,33 +0,0 @@
-= New Feature
-
-* A match_hook_args plugin has been added.  This is similar to the
-  existing match_hook plugin, but passes through the matchers and
-  block arguments (values yielded to the match block). Example:
-
-    plugin :match_hook_args
- 
-    add_match_hook do |matchers, block_args|
-      logger.debug("matchers: #{matchers.inspect}. #{block_args.inspect} yielded.")
-    end
-
-    # Term is an implicit matcher used for terminating matches, and
-    # will be included in the array of matchers yielded to the match hook
-    # if a terminating match is used.
-    term = self.class::RodaRequest::TERM
-
-    route do |r|
-      r.root do
-        # for a request for /
-        # matchers: nil, block_args: nil
-      end
-
-      r.on 'a', ['b', 'c'], Integer do |segment, id|
-        # for a request for /a/b/1
-        # matchers: ["a", ["b", "c"], Integer], block_args: ["b", 1]
-      end
-
-      r.get 'd' do
-        # for a request for /d
-        # matchers: ["d", term], block_args: []
-      end
-    end

data/doc/release_notes/3.72.0.txt

@@ -1,48 +0,0 @@
-= New Features
-
-* An invalid_request_body plugin has been added for allowing custom
-  handling of invalid request bodies.  Roda uses Rack's request body
-  parsing, and by default invalid request bodies can result in
-  different exceptions based on how the body is invalid and which
-  version of Rack is in use.
-
-  If you want to treat an invalid request body as the submission of
-  no parameters, you can use the :empty_hash argument when loading
-  the plugin:
-
-    plugin :invalid_request_body, :empty_hash
-
-  If you want to return a empty 400 (Bad Request) response if an
-  invalid request body is submitted, you can use the :empty_400
-  argument when loading the plugin:
-
-    plugin :invalid_request_body, :empty_400
-
-  If you want to raise a Roda::RodaPlugins::InvalidRequestBody::Error
-  exception if an invalid request body is submitted (which makes it
-  easier to handle these exceptions when using the error_handler
-  plugin), you can use the :raise argument when loading the plugin:
-
-    plugin :invalid_request_body, :raise
-
-  For custom behavior, you can pass a block when loading the plugin
-  The block is called with the exception Rack raised when parsing the
-  body. The block will be used to define a method in the application's
-  RodaRequest class.  It can either return a hash of parameters, or
-  you can raise a different exception, or you can halt processing and
-  return a response:
-
-    plugin :invalid_request_body do |exception|
-      # To treat the exception raised as a submitted parameter
-      {body_error: exception}
-    end
-
-= Other Improvements
-
-* When using the check_arity: :warn Roda option, Roda now correctly
-  warns when defining a method that expects a single argument when
-  the provided block requires multiple arguments.
-
-* The match_hooks plugin is now implemented using the match_hook_args
-  plugin, simplifying the implementation.  This change should be
-  transparent unless you were reaching into the internals.

data/doc/release_notes/3.73.0.txt

@@ -1,33 +0,0 @@
-= New Features
-
-* The middleware plugin now accepts a :next_if_not_found option.
-  This allows the middleware plugin to pass the request to the next
-  application if the current application handles the request but
-  ends up calling the not_found handler.  With the following
-  middleware:
-
-    class Mid < Roda
-      plugin :middleware
-
-      route do |r|
-        r.on "foo" do
-          r.get "bar" do
-            'bar'
-          end
-        end
-      end
-    end
-
-  Requests for /x would be forwarded to the next application, since
-  the application doesn't handle the request, but requests for /foo/x
-  would not be, because the middleware is partially handling the
-  request in the r.on "foo" block.  With the :next_if_not_found
-  option, only requests for /foo/bar would be handled by the
-  middleware, and all other requests would be forwarded to the next
-  application.
-
-= Other Improvements
-
-* The sessions and route_csrf plugins no longer depend on the base64
-  library. base64 will be removed from Ruby's standard library
-  starting in Ruby 3.4.

data/doc/release_notes/3.74.0.txt

@@ -1,28 +0,0 @@
-= New Features
-
-* A redirect_http_to_https plugin has been added, redirecting HTTP
-  requests to the same path on an HTTPS site.  Using the routing tree,
-  you can control where to do the redirection, which allows you to
-  easily have part of your site accessible via HTTP, with sensitive
-  sections requiring HTTPS:
-
-    plugin :redirect_http_to_https
-
-    route do |r|
-      # routes available via both HTTP and HTTPS
-      r.redirect_http_to_https
-      # routes available only via HTTPS
-    end
-
-  If you want to redirect to HTTPS for all routes in the routing tree, you
-  can have r.redirect_http_to_https as the very first method call in the
-  routing tree.  Note that in Roda it is possible to handle routing before
-  the normal routing tree using before hooks.  The static_routing and
-  heartbeat plugins use this feature. If you would like to handle routes
-  before the normal routing tree, you can setup a before hook:
-
-    plugin :hooks
-
-    before do
-      request.redirect_http_to_https
-    end

data/doc/release_notes/3.75.0.txt

@@ -1,19 +0,0 @@
-= New Features
-
-* A cookie_flags plugin has been added, for overriding, warning, or
-  raising for incorrect cookie flags. The plugin by default checks
-  whether the secure, httponly, and samesite=strict flags are set.
-  The default behavior is to add the appropriate flags if they are
-  not set, and change the samesite flag to strict if it is set to
-  something else.  You can configure the flag checking behavior
-  via the :httponly, :same_site, and :secure options.
-
-  You can configure the action the plugin takes via the :action option.
-  The default action is to modify the flags, but the :action option can
-  be set to :raise, :warn, or :warn_and_modify to override the behavior.
-
-  The recommended way to use the plugin is to use it during testing,
-  and specify action: :raise, so you can catch places where cookies
-  are set with the wrong flags.  Then you can fix those places to
-  use the correct flags, which is better than relying on the plugin
-  at runtime in production to fix incorrect flags.

data/doc/release_notes/3.76.0.txt

@@ -1,18 +0,0 @@
-= New Features
-
-* A break plugin has been added, allowing you to use break from
-  inside a routing block and continue routing after the block.  This
-  offers the same feature as the pass plugin, but using the standard
-  break keyword instead of the r.pass method.
-
-* The error_mail and error_email features now both accept a :filter
-  plugin option.  The value should respond to call with two arguments.
-  The first arguments is the key, and the second is the value, and
-  should return a truthy value if the value should be filtered.  This
-  will be used for filtering parameter values, ENV values, and session
-  values in the generated emails.
-
-= Other Improvements
-
-* On Ruby 3.3+, the middleware plugin sets a temporary class name for
-  the created middleware, based on the class name of the Roda app.

data/doc/release_notes/3.77.0.txt

@@ -1,8 +0,0 @@
-= New Features
-
-* The route_csrf plugin now supports formaction/formmethod attributes
-  in forms. A csrf_formaction_tag method has been added for creating
-  a hidden input for a particular path and method.  When a form is
-  submitted, the check_csrf! method will fix check for a path-specific
-  csrf token (set by the hidden tag added by the csrf_formaction_tag
-  method), before checking for the default csrf token.

data/doc/release_notes/3.78.0.txt

@@ -1,99 +0,0 @@
-= New Features
-
-* A permissions_policy plugin has been added that allows you to easily set a
-  Permissions-Policy header for the application, which browsers can use to
-  determine whether to allow specific functionality on the returned page
-  (mainly related to which JavaScript APIs the page is allowed to use).
-
-  You would generally call the plugin with a block to set the default policy:
-
-    plugin :permissions_policy do |pp|
-      pp.camera :none
-      pp.fullscreen :self
-      pp.clipboard_read :self, 'https://example.com'
-    end
-
-  Then, anywhere in the routing tree, you can customize the policy for just that
-  branch or action using the same block syntax:
-
-    r.get 'foo' do
-      permissions_policy do |pp|
-        pp.camera :self
-      end
-      # ...
-    end
-
-  In addition to using a block, you can also call methods on the object returned
-  by the method:
-
-    r.get 'foo' do
-      permissions_policy.camera :self
-      # ...
-    end
-
-  You can use the :default plugin option to set the default for all settings.
-  For example, to disallow all access for each setting by default:
-
-    plugin :permissions_policy, default: :none
-
-  The following methods are available for configuring the permissions policy,
-  which specify the setting (substituting _ with -): 
-
-  * accelerometer
-  * ambient_light_sensor
-  * autoplay
-  * bluetooth
-  * camera
-  * clipboard_read
-  * clipboard_write
-  * display_capture
-  * encrypted_media
-  * fullscreen
-  * geolocation
-  * gyroscope
-  * hid
-  * idle_detection
-  * keyboard_map
-  * magnetometer
-  * microphone
-  * midi
-  * payment
-  * picture_in_picture
-  * publickey_credentials_get
-  * screen_wake_lock
-  * serial
-  * sync_xhr
-  * usb
-  * web_share
-  * window_management
-
-  All of these methods support any number of arguments, and each argument should
-  be one of the following values:
-
-  :all :: Grants permission to all domains (must be only argument)
-  :none :: Does not allow permission at all (must be only argument)
-  :self :: Allows feature in current document and any nested browsing contexts
-           that use the same domain as the current document.
-  :src :: Allows feature in current document and any nested browsing contexts
-          that use the same domain as the src of the iframe.
-  String :: Specifies origin domain where access is allowed
-
-  When calling a method with no arguments, the setting is removed from the policy instead
-  of being left empty, since all of these setting require at least one value.  Likewise,
-  if the policy does not have any settings, the header will not be added.
-
-  Calling the method overrides any previous setting.  Each of the methods has +add_*+ and
-  +get_*+ methods defined. The +add_*+ method appends to any existing setting, and the +get_*+ method
-  returns the current value for the setting (this will be +:all+ if all domains are allowed, or
-  any array of strings/:self/:src).
-
-    permissions_policy.fullscreen :self, 'https://example.com'
-    # fullscreen (self "https://example.com")
-
-    permissions_policy.add_fullscreen 'https://*.example.com'
-    # fullscreen (self "https://example.com" "https://*.example.com")
-
-    permissions_policy.get_fullscreen
-    # => [:self, "https://example.com", "https://*.example.com"]
-
-  The clear method can be used to remove all settings from the policy.

data/doc/release_notes/3.79.0.txt

@@ -1,148 +0,0 @@
-= New Features
-
-* The hmac_paths plugin allows protection of paths using an HMAC.  This can be used
-  to prevent users enumerating paths, since only paths with valid HMACs will be
-  respected.
-  
-  To use the plugin, you must provide a :secret option.  This sets the secret for
-  the HMACs.  Make sure to keep this value secret, as this plugin does not provide
-  protection against users who know the secret value.  The secret must be at least
-  32 bytes.
-  
-    plugin :hmac_paths, secret: 'some-secret-value-with-at-least-32-bytes'
-  
-  To generate a valid HMAC path, you call the hmac_path method:
-  
-    hmac_path('/widget/1')
-    # => "/0c2feaefdfc80cc73da19b060c713d4193c57022815238c6657ce2d99b5925eb/0/widget/1"
-  
-  The first segment in the returned path is the HMAC.  The second segment is flags for
-  the type of paths (see below), and the rest of the path is as given.
-  
-  To protect a path or any subsection in the routing tree, you wrap the related code
-  in an +r.hmac_path+ block.
-  
-    route do |r|
-      r.hmac_path do
-        r.get 'widget', Integer do |widget_id|
-          # ...
-        end
-      end
-    end
-  
-  If first segment of the remaining path contains a valid HMAC for the rest of the path (considering
-  the flags), then r.hmac_path will match and yield to the block, and routing continues inside
-  the block with the HMAC and flags segments removed.
-  
-  In the above example, if you provide a user a link for widget with ID 1, there is no way
-  for them to guess the valid path for the widget with ID 2, preventing a user from
-  enumerating widgets, without relying on custom access control.  Users can only access
-  paths that have been generated by the application and provided to them, either directly
-  or indirectly.
-  
-  In the above example, r.hmac_path is used at the root of the routing tree. If you
-  would like to call it below the root of the routing tree, it works correctly, but you
-  must pass hmac_path the :root option specifying where r.hmac_paths will be called from.
-  Consider this example:
-  
-    route do |r|
-      r.on 'widget' do
-        r.hmac_path do
-          r.get Integer do |widget_id|
-            # ...
-          end
-        end
-      end
-  
-      r.on 'foobar' do
-        r.hmac_path do
-          r.get Integer do |foobar_id|
-            # ...
-          end
-        end
-      end
-    end
-  
-  For security reasons, the hmac_path plugin does not allow an HMAC path designed for
-  widgets to be a valid match in the r.hmac_path call inside the "r.on 'foobar'"
-  block, preventing users who have a valid HMAC for a widget from looking at the page for
-  a foobar with the same ID.  When generating HMAC paths where the matching r.hmac_path
-  call is not at the root of the routing tree, you must pass the :root option:
-  
-    hmac_path('/1', root: '/widget')
-    # => "/widget/daccafce3ce0df52e5ce774626779eaa7286085fcbde1e4681c74175ff0bbacd/0/1"
-  
-    hmac_path('/1', root: '/foobar')
-    # => "/foobar/c5fdaf482771d4f9f38cc13a1b2832929026a4ceb05e98ed6a0cd5a00bf180b7/0/1"
-  
-  Note how the HMAC changes even though the path is the same.
-  
-  In addition to the +:root+ option, there are additional options that further constrain
-  use of the generated paths.
-  
-  The :method option creates a path that can only be called with a certain request
-  method:
-  
-    hmac_path('/widget/1', method: :get)
-    # => "/d38c1e634ecf9a3c0ab9d0832555b035d91b35069efcbf2670b0dfefd4b62fdd/m/widget/1"
-  
-  Note how this results in a different HMAC than the original hmac_path('/widget/1')
-  call.  This sets the flags segment to "m", which means r.hmac_path will consider the
-  request mehod when checking the HMAC, and will only match if the provided request method
-  is GET.  This allows you to provide a user the ability to submit a GET request for the
-  underlying path, without providing them the ability to submit a POST request for the
-  underlying path, with no other access control.
-  
-  The :params option accepts a hash of params, converts it into a query string, and
-  includes the query string in the returned path.  It sets the flags segment to +p+, which
-  means r.hmac_path will check for that exact query string.  Requests with an empty query
-  string or a different string will not match.
-  
-   hmac_path('/widget/1', params: {foo: 'bar'})
-   # => "/fe8d03f9572d5af6c2866295bd3c12c2ea11d290b1cbd016c3b68ee36a678139/p/widget/1?foo=bar"
-  
-  For GET requests, which cannot have request bodies, that is sufficient to ensure that the
-  submitted params are exactly as specified. However, POST requests can have request bodies,
-  and request body params override query string params in r.params.  So if you are using
-  this for POST requests (or other HTTP verbs that can have request bodies), use r.GET
-  instead of r.params to specifically check query string parameters.
-  
-  You can use +:root+, +:method+, and +:params+ at the same time:
-  
-    hmac_path('/1', root: '/widget', method: :get, params: {foo: 'bar'})
-    # => "/widget/9169af1b8f40c62a1c2bb15b1b377c65bda681b8efded0e613a4176387468c15/mp/1?foo=bar"
-  
-  This gives you a path only valid for a GET request with a root of "/widget" and
-  a query string of "foo=bar".
-  
-  To handle secret rotation, you can provide an :old_secret option when loading the
-  plugin.
-  
-    plugin :hmac_paths, secret: 'some-secret-value-with-at-least-32-bytes',
-                        old_secret: 'previous-secret-value-with-at-least-32-bytes'
-  
-  This will use :secret for constructing new paths, but will respect paths generated by
-  :old_secret.
-
-= Other Improvements
-
-* When not using cached templates in the render plugin, the render plugin
-  now has better handling when a template is modified and results in an
-  error.  Previously, the error would be raised on the first request after
-  the template modification, but subsequent requests would use the
-  previous template value.  The render plugin will no longer update the
-  last modified time in this case, so if a template is modified and
-  introduces an error (e.g. SyntaxError in an erb template), all future
-  requests that use the template will result in the error being raised,
-  until the template is fixed.
-
-= Backwards Compatibility
-
-* The internal TemplateMtimeWrapper API has been modified.  As documented,
-  this is an internal class and the API can change in any Roda version.
-  However, if any code was relying on the previous implementation of
-  TemplateMtimeWrapper#modified?, it will need to be modified, as that
-  method has been replaced with TemplateMtimeWrapper#if_modified.
-
-  Additionally, the TemplateMtimeWrapper#compiled_method_lambda API has
-  also changed.

data/doc/release_notes/3.8.0.txt

@@ -1,27 +0,0 @@
-= New Features
-
-* The convert_each! method in the typecast_params plugin now
-  accepts a Proc or Method value for the :keys option. The proc
-  or method is called with the current array or hash that
-  typecast params is operating on, and should return an
-  array of keys to use for the conversion.
-
-* The convert_each! method in the typecast_params plugin will
-  now automatically handle hashes with keys from '0'..'N',
-  without a :keys option being provided.
-  
-  This makes it possible to handle parameter names such as
-  foo[0][bar], foo[0][baz], foo[1][bar], and foo[1][baz], if you
-  want to avoid the issues related to rack's issues when parsing
-  array parameters.
-
-= Other Improvements
-
-* The Roda::RodaVersionNumber constant has been added for easier
-  version comparisons.  It is 30080 for version 3.8.0.
-
-= Backwards Compatibility
-
-* When an unsupported type is given as value of the :keys option
-  to the convert_each! method in the typecast_params plugin, a
-  ProgrammerError exception is now raised.

data/doc/release_notes/3.80.0.txt

@@ -1,31 +0,0 @@
-= New Features
-
-* The hmac_paths plugin now supports a :namespace option for both hmac_path and
-  r.hmac_path.  The :namespace option makes the generated HMAC values unique
-  per namespace, allowing easy use of per user/group HMAC paths. This can
-  be useful if the same path will show different information to different
-  users/groups, and you want to prevent path enumeration for each user/group
-  (not allow paths enumerated by one user/group to be valid for a different
-  user/group). Example:
-
-    hmac_path('/widget/1', namespace: '1')
-    # => "/3793ac2a72ea399c40cbd63f154d19f0fe34cdf8d347772134c506a0b756d590/n/widget/1"
-
-    hmac_path('/widget/1', namespace: '2')
-    # => "/0e1e748860d4fd17fe9b7c8259b1e26996502c38e465f802c2c9a0a13000087c/n/widget/1"
-  
-  The HMAC path created with namespace: '1' will only be valid when calling
-  r.hmac_path with namespace: '1' (similar for namespace: '2').
-
-  It is expected that the most common use of the :namespace option is to
-  reference session values, so the value of each path depends on the logged in
-  user.  You can use the :namespace_session_key plugin option to set the
-  default namespace for both hmac_path and r.hmac_path:
-
-    plugin :hmac_paths, secret: 'some-secret-value-with-at-least-32-bytes',
-           namespace_session_key: 'account_id'
-
-  This will use <tt>session['account_id']</tt> (converted to a string) as the namespace
-  for both hmac_path and r.hmac_path, unless a specific :namespace option is
-  given, making it simple to implement per user/group HMAC paths across an
-  application.