Forum: RSpec Cucumber, Webrat and http basic auth

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
kwe (Guest)
on 2008-11-20 12:34
(Received via mailing list)
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
aslak hellesoy (Guest)
on 2008-11-20 13:12
(Received via mailing list)
On Thu, Nov 20, 2008 at 11:32 AM, kwe <removed_email_address@domain.invalid> 
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:
http://github.com/brynary/webrat/commit/17cf56eb5e...

Are you using this?

Aslak
kwe (Guest)
on 2008-11-20 15:52
(Received via mailing list)
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" <removed_email_address@domain.invalid>
aslak hellesoy (Guest)
on 2008-11-20 16:09
(Received via mailing list)
On Thu, Nov 20, 2008 at 2:52 PM, kwe <removed_email_address@domain.invalid> 
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
Andrew P. (Guest)
on 2008-11-20 16:46
(Received via mailing list)
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 <removed_email_address@domain.invalid>:
Chris F. (Guest)
on 2008-11-20 17:16
(Received via mailing list)
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.
Josh K. (Guest)
on 2008-11-20 17:28
(Received via mailing list)
On Thu, Nov 20, 2008 at 10:15 AM, Chris F. 
<removed_email_address@domain.invalid>
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 <action>_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:  removed_email_address@domain.invalid
web:    http://joshknowles.com
Chris F. (Guest)
on 2008-11-23 19:21
(Received via mailing list)
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/4131b8da2fec4...
that should do the trick for the redirects.
This topic is locked and can not be replied to.