Cucumber, Webrat and http basic auth

Testing RSpec
1

Starting out with Cucumber and webrat and seem to be hitting a problem
with a resource protected with http basic auth.

i.e.

The following feature…

Feature: Manage Pages
In order to add a reference pages
As a administrator
I want to create a page

Scenario: Add a page
Given I am logged in
And I am on the new page page
Then I should see “New page”
When I fill in “page_title” with “Demo Page”
And I fill in “page_summary” with “A short trip to the loo”
And I fill in “page_body” with “A very long long long story”
And I press “Create”
Then I should see “Show Page: Demo Page”

with the step “Given I am logged in” defined as…

Given /^I am logged in$/ do
basic_auth(‘username’, ‘apassword’)
end

All the steps work and a record is created, but the last step fails
with a “HTTP Basic: Access denied”

test.log has a

Processing PagesController#show (for 127.0.0.1 at 2008-11-19 22:52:23)
[GET]
Session ID:
BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo
SGFzaHsGOgtub3RpY2UiI1BhZ2Ugd2FzIHN1Y2Nlc3NmdWxseSBjcmVhdGVk
LgY6CkB1c2VkewY7BkY=–fb242e74f0776d7728d62c6224c763ed60ad7064
Parameters: {“action”=>“show”, “id”=>“1-demo-page”,
“controller”=>“admin/pages”}
Filter chain halted as [:authenticate] rendered_or_redirected.
Completed in 0.00095 (1053 reqs/sec) | Rendering: 0.00081 (85%) | DB:
0.00000 (0%) | 401 Unauthorized [http://www.example.com/admin/pages/1-
demo-page]

The :authenticate it refers to is a pretty standard…

def authenticate
authenticate_or_request_with_http_basic(“no peeping”) do |
username, password|
username == ‘username’ && password == ‘apassword’
end
end

I’m assuming it’s possibly an implementation problem with webrat?!?!
Given that the steps to fill out the form and press the create button
work fine (HTTP_AUTHORIZATION is passed in the heads for each action),
but sadly not for the redirect that follows the creation of a record.

Any ideas how I should proceed?

with thanks
Kevin

2

On Thu, Nov 20, 2008 at 11:32 AM, kwe [email protected] wrote:

I want to create a page

0.00000 (0%) | 401 Unauthorized [http://www.example.com/admin/pages/1-

I’m assuming it’s possibly an implementation problem with webrat?!?!

I added basic auth support to webrat a few weeks back, and Bryan pulled
it in:

Are you using this?

Aslak

3

Yes, using latest webrat and cucumber, basic_auth is working for the
initial steps, just not for the redirect that follows a successful
‘page’ creation i.e.

redirect_to(admin_page_path(@page))

In a Rails sense.

On Nov 20, 11:11 am, “aslak hellesoy” [email protected]

4

On Thu, Nov 20, 2008 at 2:52 PM, kwe [email protected] wrote:

Yes, using latest webrat and cucumber, basic_auth is working for the
initial steps, just not for the redirect that follows a successful
‘page’ creation i.e.

redirect_to(admin_page_path(@page))

In a Rails sense.

Sorry - should have read your mail more closely. Then it might be a bug.

Aslak

5

Don’t know if this is related, but webrat 0.3.4 introduced a bug with
redirecting which I reported at

http://webrat.lighthouseapp.com/projects/10503/tickets/67

Wonder if your problem happens with webrat 0.2?

2008/11/20 aslak hellesoy [email protected]:

6

On Thu, Nov 20, 2008 at 10:15 AM, Chris F. [email protected]
wrote:

I ended up patching webrat to avoid the post_via_redirect rails methods, and
had to implement a version of follow_redirects that takes headers as an
argument.

I’ve refactored the way that redirects are handled in Rails away from
the _with_redirect style in my webrat fork
(http://github.com/joshknowles/webrat) which may make your work
easier.

–
Josh K.
phone: 509-979-1593
email: [email protected]
web: http://joshknowles.com

7

Yes. I’ve actually had to patch webrat (behind a firewall,
unfortunately)
to deal with this. Havn’t had a chance to actually extract from the
firewall.

It’s not actually Webrat’s fault, at least from what I’ve managed to
uncover. The problem lies within the Rails integration tests;
specifically
that follow_redirect (which webrat uses for posts, puts and deletes)
doesn’t
have a mechanism for passing on headers for the followup redirects.

webrat makes POST to /foos, sends http headers # uses rails
post_via_redirect method
controller responds with redirect to /foos/1
rails integration tests follows redirects # with follow_redirect!
while
redirect?

If /foos/1 happens to require basic auth, things go boom, because
follow_redirect! has no mechanism for sending your own headers.

I ended up patching webrat to avoid the post_via_redirect rails methods,
and
had to implement a version of follow_redirects that takes headers as an
argument. So, instead of using the rails post_via_redirect, I do
something
like this:

rails_session.rb

def post(url, data, headers = nil)
@integration_session.post(remove_protocol(url), data, headers)
@integration_session.follow_all_redirects_with_headers!(headers)
end

session.rb

def follow_all_redirects_with_headers!(h)
follow_redirect_with_headers!(h) while redirect?
end

def follow_redirect_with_headers!(h)

largely copied from within rails source…

raise “not a redirect!” unless redirect?
h[‘HTTP_REFERER’] = current_url if current_url
get(interpret_url(headers[‘location’].first, {}, h)
status
end

I’ll try and get this outside the firewall and into a github fork. I’m
not
convinced this was the best way to deal with the problem, but it’s
worked
for me so far.

8

Thanks. I had some similar bits already in place, but yours is much
better put together for deciding when to redirect.

I’ve got a patch up at
http://github.com/flip/webrat/commit/4131b8da2fec44398fb170f4d88edc36ad9c9cac
that should do the trick for the redirects.