Bugs item #3458404, was opened at 2011-12-12 15:45
Message generated for change (Comment added) made by bagder
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: Pending
>Resolution: Invalid
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: Daniel Stenberg (bagder)
Date: 2012-01-18 14:35

Message:
Thanks for reporting this issue and helping us improve curl and libcurl.

We're awaiting feedback in this issue. Due to this, I have set the state of
this issue to pending and it will automatically get closed later on unless
we get further info.

Please consider answering the outstanding questions or providing the
missing info so that we can proceed to resolve this issue!

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

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

Message:
I love bug reports. I don't mind them pointing out flaws as I know they
always exist. I mind aggressive attitudes.

You're pointing out a possible flaw in the SSPI parts of the code that
probably always existed. I doubt it is a regression. If this is so, I don't
consider this to be a "serious bug that renders your software unusable".
Far from it. curl and libcurl are used by millions and most users never
come close to SSPI. But the exact severeness degree isn't that important
here.

SSPI is a windows-specific technology and I thought it was about using
credentials and info from the already-logged-in user.

I personally don't run or use Windows so I can't test anything with SSPI
and I've not developed those parts.

As I understood things you're using NTLM and I've written most of the
non-SSPI NTLM code and therefore it would be interesting to see if your
problem remains if you use the "native" NTLM functionality instead of the
SSPI one.

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

Comment By: Kris Craig (sir_kris)
Date: 2011-12-16 10:31

Message:
@bagder Yikes please try to calm down! Nobody is threatening you. If you
got that impression, then I apologize for not making myself clearer. I was
attempting to convey the flatly prohibitive roadblock this bug creates for
the implementation of modern website designs. I'm not "threatening" to
stop using cURL in order to coerce you. I'm merely pointing out that I
will literally have no other choice but to find compatible alternatives and
that, if not addressed, over time this will most likely lead to an errosion
of cURL's user base. I warned you about this likely scenario because I
think you deserve to know, and since you're not a PHP developer you might
not be aware of just how prohibitive this problem is.

So if that rubbed you the wrong way, please accept my apologies for not
being more tactful. However, cURL is by far the best solution for making
HTTP requests in PHP and I don't want this bug to force me to use something
that is otherwise less robust. I spend a lot of time contributing to OSS
projects myself, so I understand where you're coming from. It's easy to
get defensive when someone comes out of nowhere telling you there's a
serious bug that renders your software unusable for a purpose that is
growing into a mainstream practice. I just hope you can reciprocate by
understanding that I'm only trying to help by bringing this to your
attention and that this bug is currently blocking me from completing a
project for my employer with the specifications they requested. It's not
meant as a threat; just a simple fact, one which I'd really, really like to
avoid, especially since it would require that I rewrite a large portion of
the code. It would have been wrong for me not to warn you about that
likely outcome simply because such a warning might offend you. What you do
with that information is entirely up to you. I was just giving you a
heads-up so you won't be blindsighted later on (that's happened to me
before; it's much more annoying to me when people don't bother to tell me
that a bug is so prohibitive that they'd be blocked by it). If a fire
fighter tells me that plugging too many appliances into the same outlet
will likely lead to a fire, I wouldn't regard that as a threat but as a
well-intended warning. The same principle applies here.

Ok, so hopefully that settles that. Again, I apologize if bringing that to
your attention caused you offense. I hope you now understand that it was
neither a threat nor an attempt to coerce you.

I've never used cURL outside of PHP before, but I can figure it out. I'll
need a little bit of time to recreate the conditions you requested, so
please stand by for now. I'll post a follow-up comment when I have the
results for you.

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

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

Message:
Please drop that "you should my issues or you will suffer" attitude. We all
work on curl on our spare time, and you can help out and fix the issues
just as much as anyone else. You and us, all together. Threatening us with
silly things like you'll stop using curl will only make me LESS reluctant
to do anything at all.

Now, back to the issue.

Can we please switch to talk plain command line tool options ? I don't know
or use PHP anywhere so it makes real block for me when debugging.

Can you try a build without SSPI and see if NTLM works for you then? I
don't run or use Windows so SSPI is a bit magic and black box to me, and it
would be nice to narrow down where the problem actually is and isn't.

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

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 2012-01-18