Allow basic authentication to be case insensitive as per the HTTP 1.1 spec RFC 2068 Section 11
> It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.
We have a particular client in production that has basic auth hard-coded as `basic` rather than `Basic` and devise is rejecting perfectly fine credentials. Making this small change has allowed us to authenticate this client with no issues.
I'm not hugely familiar with ruby internals vis a vis sclass semantics,
but this *probably* serves as a workaround for the MRI thread-safety
bug mentioned in #3505.
Beyond that, and even if this doesn't fix the thread-safety issue, per
[this blog post][1], `define_method` is recommended over `class_eval`
for performance (and, fwiw, readability) reasons anyway.
[1]: http://tenderlovemaking.com/2013/03/03/dynamic_method_definitions.html
This logic is generic and reusable -- hash a secret; and take an
unhashed secret and compare it to a hashed secret. This breaks this out
to make it reusable in other places. Specifically, we use this in our
own token auth at Bonobos that we plan to split out as a Devise
extension. This will make that possible without copy & pasting this
code.
Now that Rails 3.1 is not supported anymore, we don't need to implement
to_xml, since it does the right thing by calling serializable_hash.
This removes the class_eval need that existed to simplify the
implementation of both to_xml and serializable_hash.
Devise.available_router_name currently returns either
Devise.router_name or :main_app. As such, any redirecting is done
within either of those contexts. Which leads to undesirable redirects
for scopes that reside in an isolate_namespace mounted engine.
This commit makes it possible for FailureApp’s redirect behavior to be
performed in the context of the router_name given to devise_for.
Test case added to cover undesirable behavior. Without change to
lib/devise/failure_app.rb, test case throws exception.
In order to be more clear about the expectations of for authenticating, we use
`password.present?` so there is no confusion about the role of the `valid_password?`
method.
More info: https://github.com/plataformatec/devise/issues/3519
Introspecting the scope of an object can make it difficult to use
wrapper patterns. See issue plataformatec/devise#3307 for an example.
Allow objects to specify their scope explicitly by implementing
`devise_scope`.
