cURL / Mailing Lists / curl-and-php / Single Mail

curl-and-php

Re: Authentication troubles (possible bug?)

From: <earmstr2_at_csc.com>
Date: Fri, 9 Mar 2001 09:27:40 -0500

The mail server in this place refuses to send messages to contactor.se so
if you don't mind, I'd like continue the conversation here.

I had orginally tried to get this to work with cURL.exe for Win32. I never
did get it work and I strong suspect the behavior that I'm seeing is some
kind of bug (either in Extraweb or cURL). Basically, if I type the
following into my web browser (IE 5.5with both file and session cookies
disabled) it works:

https://eweb01.asp.dupont.com/__extraweb__authen?data_0=USERNAME&data_1=PASSWORD&resource
=%2FNASApp%2FCleaning_Chemicals%HelloWorldServlet&session=1292&numitems=2&method=2&s_button=%20OK%20

By "works" I mean that I end up at
https://eweb01.asp.dupont.com/NASApp/Cleaning_Chemicals/HelloWorldServlet
after the appropriate authentication and redirection.

Now, if I do the following in cURL:

curl -v -i -L -b z -d "data_0=USERNAME&data_1=PASSWORD&resource
=%2FNASApp%2FCleaning_Chemicals%HelloWorldServlet&session=1292&numitems=2&method=2&s_button=%20OK%20" https://eweb01.asp.dupont.com/__extraweb__authen

I get:

-snip-

* SSL connection using DES-CBC3-SHA
* Server certificate:
* subject: /C=US/ST=Delaware/L=Newark/O=E.I. du Pont de Nemours and Co. Inc/OU=DISO/CN=eweb01.asp.dupont.com
* issuer: /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
* Connected to eweb00.asp.dupont.com (52.128.224.14)
> POST /__extraweb__authen HTTP/1.0
User-Agent: curl/7.6.1 (win32) libcurl 7.6.1 (SSL 0.9.6)
Host: eweb01.asp.dupont.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Content-Length: 106
Content-Type: application/x-www-form-urlencoded

data_0=USERNAME&data_1=PASSWORD&resource=2FCleaning_Chemicals&session=1292&numitems=2&method=2&s_button=20
HTTP/1.1 302 Found
Date: Fri, 09 Mar 2001 13:56:33 GMT
Server: ExtraWeb Server/3.20 Build 39 (Unix)
Location: https://eweb01.asp.dupont.com:4432FCleaning_Chemicals
Connection: close
Content-Type: text/html

* Follow to new URL: https://eweb01.asp.dupont.com:4432FCleaning_Chemicals
* Follows Location: to new URL: 'https://eweb01.asp.dupont.com:4432FCleaning_Chemicals'
curl: (7) Can't connect to server: 2

-snip-

You can see from the above that it ALMOST works. For some reason, we've lost the % from the %2F (forward slash) so it can't resolve the proper server
 name.
I _don't_ think that this is what's happening when I use libcurl within PHP because I end up with a different problem (I wind up back at the login
screen again, although if I try to login again with the same credentials it tells me that I'm already validated so I know that things are mostly
working).

If you want a real userid and password to see this in action yourself I can e-mail you one.

Thanks for the help thus far.

Daniel Stenberg <daniel_at_haxx.se>@lists.sourceforge.net on 03/09/2001
03:51:53 AM

Please respond to curl-and-php_at_lists.sourceforge.net

Sent by: curl-and-php-admin_at_lists.sourceforge.net

To: curl and php list <curl-and-php_at_lists.sourceforge.net>
cc:
Subject: Re: Authentication troubles (possible bug?)

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
_______________________________________________
Curl-and-php mailing list
Curl-and-php_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-and-php
Received on 2001-03-09