We’ve got a Rails application just upgraded to Rails3 using Devise’s Rails3 gem for authentication. We’ve been using Capybara with Celerity backend to test some of the pages.
When accessing the application in a browser, Devise responds with a redirect to the login page when a user is trying to access a protected page/controller.
In the Rails 2.x version of Devise this used to work even if the incoming request had a blank accept header */*.
In the Rails 3 version, Devise responds with a plain text string when the accept header is blank.
The reason the blank accept header thing matters is because we’re using the Celerity backend of Capybara to test some of the pages, and apparently Celerity sends a blank accept header, and thus doesn’t get redirected by Devise. This behavior has changed from Devise for Rails 2.x to Devise for Rails 3.
Celerity fails with an UnexpectedPageException and the server log reports that the request was made with */* as accept header.
When using the Selenium/Webdriver backend on the exact same test suite, the problem goes away.
There are two ways to tackle this:
- Tell Devise to somehow always assume text/html as accept header and respond accordingly. How could that be done? Do we have to override the controllers?
- “Fix” Celerity to sent text/html as accept header. How can this be done?
- Is this an HTMLUnit problem/bug?
To me #2 looks like the “right” way to fix this, but I’m not sure if Celerity/HTMLUnit’s lack of accept header is a bug or a feature. Thoughts?
It turns out to be an issue with HTMLUnit. I’ve made a patch to the Celerity gem which you can find here: https://github.com/jarib/celerity/pull/49
It will set the default accept header to “text/html” but also adds an optional parameter to override it.