cURL
Haxx ad
libcurl

curl's project page on SourceForge.net

Sponsors:
Haxx

cURL > Mailing List > Monthly Index > Single Mail

curl-tracker Archives

[ curl-Bugs-3458404 ] Compulsively Sends "Guest" as Username (SSPI/NTLM)

From: SourceForge.net <noreply_at_sourceforge.net>
Date: Tue, 13 Dec 2011 17:17:34 -0800

Bugs item #3458404, was opened at 2011-12-12 15:45
Message generated for change (Comment added) made by sir_kris
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3458404&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Kris Craig (sir_kris)
Assigned to: Daniel Stenberg (bagder)
Summary: Compulsively Sends "Guest" as Username (SSPI/NTLM)

Initial Comment:
Version: I'm running the Windows build (VC9-ZTS) of PHP 5.3.8, which I believe is bundled with libcurl 7.21.7. It's being executed via mod_php on Apache 2.22.
OS: Windows 7 (x64)

Here's the problem: No matter what I do, libcurl will only send the username "Guest" for SSPI authentication, completely disregarding the username I specify. The server I'm testing this against is the same one (localhost) with mod_auth_sspi installed.

According to the Curl section in phpinfo(), both NTLM and SSPI are enabled.

The destination page is just a PHP script with 1 line: print_r( $_SERVER );

The domain is being passed correctly; just not the username.

When I point to the exact same URL in IE, FireFox, or Chrome, the correct domain\username is passed. It only fails in PHP/cURL.

According to Apache's access.log (relevant portion attached), the "Guest" username is what's being sent, which means this isn't a bug in mod_auth_sspi since that layer occurs later in the stack.

(Possibly separate issue?) If SSPIOmitDomain is set to "On" in httpd.conf, cURL will always fail authentication (which only happens in the browser if you get prompted and hit "Cancel" since it's configured not to check the validity of usernames). This might be a separate issue, but I thought I'd include it here just in case it might be related somehow.

Please refer to attachments.txt for full details.

----------------------------------------------------------------------

>Comment By: Kris Craig (sir_kris)
Date: 2011-12-13 17:17

Message:
To clarify, the default behavior in the browser can be circumvented. In IE
and Chrome, you do this by adding the site in question to the "Intranet
Sites" exception list. In Firefox, there's an about:config setting that
lets you do pretty much the same thing. It's when this is in place that
the browser will simply pass the currently authenticated Windows user to
the server instead of prompting for a username/password.

However, like I said this is not the default behavior. The option to pass
a specified username-- authenticated or otherwise-- should be at the
discretion of the developer.

----------------------------------------------------------------------

Comment By: Kris Craig (sir_kris)
Date: 2011-12-13 17:14

Message:
Not necessarily. In fact, the default behavior is for the web browser to
prompt for a username and password. The browser is then responsible for
determining how to authenticate this information; typically, it'll compare
the username/password against available Windows accounts and pass "Guest"
if the information is incorrect, though some older and smaller browsers may
behave differently.

However, in this case, even providing a valid username/password was
ineffective, which suggests that it's doing exactly what you're saying;
simply passing whatever user PHP is running as and ignoring everything
else. This is not, however, the correct behavior.

These two lines from the code posted are of note:

                curl_setopt( $ch, CURLOPT_HTTPAUTH, CURLAUTH_NTLM );
                curl_setopt( $ch, CURLOPT_USERPWD, $user . ":." );

Basically, the CURLOPT_USERPWD is being completely ignored. Instead, what
it should be doing is passing that username/password to the server and
allow it to decide how/whether to authenticate it or accept it at
face-value. Considering that this code is supposed to be usable in PHP on
Linux systems as well, that only makes sense.

This issue will probably come up more, as people start switching to AJAX on
their company intranet sites and they want to continue displaying
personalized content for employees without requiring password
authentication since there's no security consideration involved.

I suppose the ideal solution, however, would be to add a flag that tells
libcurl whether to attempt the authentication itself (though not sure how
that would work in non-Windows environments) or simply pass whatever it's
told to pass and let the server decide what to do with it (which should be
the default behavior).

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2011-12-13 16:37

Message:
I'm not that familiar with SSPI, but are you sure it's even possible to
specify the user name in that case? Doesn't the OS use the currently-logged
in user for SSPI? This would then be expected behaviour if PHP is running
as Guest. What happens when you use an SSPI-enabled curl from the
command-line?

----------------------------------------------------------------------

Comment By: Kris Craig (sir_kris)
Date: 2011-12-12 15:50

Message:
Oh and though it really shouldn't matter; no, the "Guest" user account on
my Windows box is NOT enabled.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3458404&group_id=976
Received on 2011-12-14

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET