Using Rails 3.1 and protecting some controller actions with HTTP
digest authentication. Some actions accept filter parameters from the
query string, and I have a button to “clear all filters”. This ‘reset’
effectively sets the query string to empty, but leaves the ‘?’ on the
URI. (1)
In Chrome, this causes the HTTP authentication to fail, while Firefox
silently removes the trailing ‘?’ and continues.
Some code examples follow, but I’m not familiar enough with the HTTP
specs to say if this is a bug in
ActionController::HttpAuthentication::Digest#validate_digest_response
or if the bug lies in Rack::Request#fullpath.
Here’s the gist of my controller
class SecureController
before_filter :authenticate!
def secret
# do some secure stuff
end
def authenticate!
authenticate_or_request_with_http_digest(“my_realm”) do |username|
USERS[username] # assume this is a username/digest hash defined
elsewhere
end
end
end
STEPS TO REPRODUCE:
navigate to http://localhost:3000/secure/secret
=> prompted for username and password
enter valid user credentials
=> access granted, page renders
filter data with a query, e.g.
http://localhost:3000/secure/secret?foo=bar
=> filtered data is returned
reset filter, e.g. http://localhost:3000/secure/secret? (2)
=> authentication fails, even with valid username/password
In Chrome, the filter reset leaves the URL with a trailing ‘?’. In
FireFox, the ‘?’ is removed. However, if I manually type in the
address http://localhost:3000/secure/secret? in FireFox, the
authentication failure is replicated.
Actually, the filters and button are all generated automatically with
Active Admin…
The code to reset the filters is actually JavaScript and is as
follows:
$(".clear_filters_btn").click(function(){
window.location.search = “”;
return false;
});
NB: I have also reported this as a bug on the Rails Github page: