On Thu, 8 Mar 2001 Edward_A_Armstrong/CEG/CSC_at_csc.com wrote:

> Instead of using the basic Apache login/pass prompt, however, Extraweb
> pops up a web page to capture you credentials and then forwards you to
> the proper page. It does this by HTTP posting your requested location on
> the web server, your username and password and your session number back
> to itself. If it passes, it uses a redirect in the header to forward you
> to the requested page. My problem is that I although I can post in the
> proper values and Extraweb does indeed authenticate me (I can tell that
> I'm authenticated because the next time I access the page with that same
> session it tells me that I'm already authenticated) the redirect to the
> page with the contact that I'm after fails.

Let me just check if I understood this correctly. You simply want to POST to
a certain URL with your name+password and whatever, and then the server will
reply back a Location: header that when you follow it will reveal the page
you wanted in the first place?

> I'm guessing that this happens because cURL is either posting the the
> login information to the new URL again, or because Apache is telling
> Aventail Extraweb that I'm not an authenticated user.

You can easily find out what curl does by using the -v option, then you won't
have to wonder about its actions anymore.

> Perhaps this problem could be avoided with the use of a persistent
> connection.

I doubt that. I mean, I can't know for sure, but it would seem very odd for
someone to implement a add-on to a web server that requires persistent
connections for it to work. If so, it should probably not give you access in
the first place as curl (7.6.1 and earlier) uses HTTP 1.0 which doesn't do
peristant connections by default and it doesn't enable it either.

> I strongly suspect that it's one of the two that's biting me here.
> Sadly, I'm not permitted to publicly post the URLs in question to the
> list, but if anyone wants to investigate the problem via e-mail I will be
> be able to provide more specific test cases.

I don't think we need the particular URLs to at least offer some advice on
how to go on.

This is how I would go ahead:

* Use the command line client alone, it makes it faster and easier to
  debug IMHO (and thus post future questions to the main curl list instead)

* If possible, snoop on the traffic your favourite browser sends and receives
  and compare to what curl sends and receives.

* What troubles me is how this concept is designed to work. When you 'login'
  with that initial POST and you get redirected to a different page with a
  (301? 303?) Location:, to get to see a page the server considers you
  authenticated for. What if you follow a link from that page? You can't
  possible continue POSTing your way through the site.

  My guess is that there's a use of cookies here. When you get the redirect,
  you also get a set of cookies that you need to pass along on the following
  requests. Quite possibly, they're also updated along the way to better
  detect timeouts for autologouts and similar.

Emulating browsers can be a tedious task.

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/
_______________________________________________
Curl-and-php mailing list
Curl-and-php_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-and-php