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: 5
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-14 09:48

Message:
That's the thing, I did provide both user name and password. It still sent
"Guest" instead.

If the existing API's are what it's using, perhaps that should change,
because all the major web browsers then are clearly not using those API's.
This is an issue that's going to come up more and more as people start
switching over to AJAX and MVC. The current inability to specify a
username to be sent via SSPI-- which is possible in all major browsers-- is
prohibitive and will ultimately force people to look for non-cURL solutions
for backend HTTP retrieval.

PHP captures the SSPI username sent by the browser. The innerHTML of a div
is then updated via AJAX and routed through an MVC architecture for output
control, which retrieves the specified URL via cURL, applies whatever
filters/templating/etc to it, then outputs the final result. However,
because cURL doesn't currently support passed SSPI credentials, it's
impossible to successfully query any location that requires certain SSPI
credentials or simply uses them to display custom content (which is what
I'm trying to do).

This essentially renders cURL incompatible with any AJAX/MVC framework that
incorporates SSPI. If this ends up being judged a "won't fix," which is of
course your call to make, that will only mean an increasing number of
developers like myself will have to find or create alternatives to cURL
that do support this basic functionality.

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-12-14 01:01

Message:
(Please don't mess with the priority option, that's for us to judge.)

If you want to set a custom user that isn't the one that runs your libcurl
code, then you need to provide both user name and password. The default
SSPI stuff in libcurl automatically just uses the existing APIs so it
figures out the "Guest" thing, it isn't libcurl that makes that up.

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

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