I see your point. The problem must be with the cookies I am setting.

What I did was mimic the exact cookie that the server is setting, which
looks something like this:

CookieName=username%2Fbase64password; path=/directory/

Thing is, maybe since the php script that is sending this cookie is being
executed on my box, somehow the path is misinterpreted to represent a
directory on my server, rather than the remote server that is doing the
authentication?

Also, would you send the username/password in the SETOPT for every request,
or does that automatically trigger the server to go through its
authentication routine (which in this case results in a Location header
different from where I want to go)?

\Bryan

-----Original Message-----
From: Daniel Stenberg
To: Keller, Bryan
Cc: 'curl and php list '
Sent: 5/12/01 7:42 PM
Subject: RE: PHP/Curl: Any Way to Follow a REFRESH Meta Tag?

On Sat, 12 May 2001, Keller, Bryan wrote:

> 1. Client sends http request with username/password to server

Is this HTTP authorization, or is it a HTML form?

> 2. Server matches u/p, sends back cookies (one of which containes the
> username and the base64 encoded password), and a location header
pointing to
> the login function of the application

... so then it'll expect all your upcoming requests to send back that
cookie,
so that it can verify that you've been authorized... Are you doing that?

> 3. Login function does logic to figure out permissions, etc. and sends
a
> meta refresh tag
> 4. At this point, you extract the refresh URL, and put it in a string.
> Problem is you have to start a new curl instance (discontinuing your
> authenticated status)

There's basically only two ways a client can keep "state information"
such as
this. One way is parameters passed to the right side of a '?' in the
URL, and
the other is by using cookies. The server CAN NOT keep state information
between client requests, because for all it knows, the next request
could be
from an entirely different client/browser.

This certainly sounds as if "your" server is based on cookies.

Then you only need to tell curl what cookies to use to pass to the
server
when you get the 'refresh page'.

There is actually no such thing as "authenticated status". The HTTP
client
has to prove itself in every single request. It won't get anything for
free
just because it just made a request.

> and pass the username/password again, causing the server to redirect
you
> back to the login function, and send you the refresh again...

It does that because it doesn't get the proper "proof" that you're
authenticated. You probably must pass cookies back that you don't.

> I guess if somehow curl could follow the refresh tag, like it does the
> location headers, it might work, or am I way off?

Not entirely, I just don't think you've gotten the full picture yet.

In the lack of details, let me guess freely how things could be done:

1. Get the initial form-page, fill in your name/password with a POST.

2. Read the page you get back, store the headers with the interesting
   cookies. This page also has a refresh tag to another page.

3. Parse the page to find the new page to fetch.

4. Request the new page, pass the stored headers and tell curl to use
those
   cookies when doing so.

... or at what point does it fail?

-- 
  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