Bug 15441 – (Windows) Ignoring basic auth credentials in URL

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Dan Fabulich]

Go to an URL that uses HTTP basic authentication. rahul.net has an example page at http://joeuser:[e-mail]/joeuser/

In Safari/Windows, the credentials in the URL are ignored, and the user is prompted to enter login/password by hand.

On Firefox and Safari/Mac, the URL resolves directly; on Opera, you get a warning that "You are about to go to an address containing a username."

(You'll see a similar warning on Firefox when the password is very long, e.g. longer than 255 characters.  "You are about to log into the site 'www.rahul.net' with the username 'joeuser'."  This can be configured in Firefox's about:config panel by setting "network.http.phishy-userpass-length".)

In IE7, you get a pop-up saying "Windows cannot find 'http://joeuser:[e-mail]/joeuser/'. Check the spelling and try again."  However, the page resolves correctly if you set the registry key FEATURE_HTTP_USERNAME_PASSWORD_DISABLE to "iexplore.exe"; more information is available here: http://support.microsoft.com/kb/834489

As the MS KB article explains, this is happening because Microsoft decided that including basic authentication credentials in URLs is a fundamentally bad idea (because it makes it too easy to create phishy URLs).

The KB article explains that users of WinInet (e.g. WebKit) can pass special options to their HINTERNET handles to allow basic auth URLs to work.  (For example, InternetSetOption can set INTERNET_OPTION_USERNAME and INTERNET_OPTION_PASSWORD.)

We need to use URL-based basic authentication credentials in Selenium, the web automation framework.

IMO, Safari/Windows should behave exactly the same way as Safari/Mac, and so the InternetSetOption line should be added to ResourceHandleWin.cpp.  If this is regarded as too great a security risk, then it should at least be configurable using preferences.

[Brady Eidson]

> The KB article explains that users of WinInet (e.g. WebKit) can pass special 
> options to their HINTERNET handles to allow basic auth URLs to work. 

The "official" Windows WebKit does not use WinInet.

>IMO, Safari/Windows should behave exactly the same way as Safari/Mac

Agreed...

>and so the InternetSetOption line should be added to ResourceHandleWin.cpp

ResourceHandleWin.cpp has been touched in quite some time.  If this isn't working in the normal WebKitWin build, the reasons why are likely to exist in KURL and other url handling code, ResourceHandleCF.cpp, or the CFNetwork support library.

Note those are just the most likely candidates, a guess without looking further into the issue.

[Brady Eidson]

ResourceHandleWin.cpp has been touched in quite some time. =
ResourceHandleWin.cpp has NOT been touched in quite some time.

[Dan Fabulich]

Thanks for the prompt follow-up!

(In reply to comment #1)
> The "official" Windows WebKit does not use WinInet.

ResourceHandleWin.cpp certainly DOES use WinInet...  It includes <wininet.h> and uses HttpOpenRequestA (the ASCII version of HttpOpenRequest) to do its work.

> ResourceHandleWin.cpp has NOT been touched in quite some time.

When you say that it hasn't been "touched," do you mean that it hasn't been USED in a long time, also?  There's quite a bit of code sitting in the "network" directory there; it's hard to tell what is/isn't being used.

> If this isn't
> working in the normal WebKitWin build, the reasons why are likely to exist in
> KURL and other url handling code,

I just glanced over KURL.cpp; doesn't look particularly culpable to my novice eye.

> ResourceHandleCF.cpp, or the CFNetwork support library.

I wrongly thought that CFNetwork was Darwin-only; actually, I thought it was just a part of Darwin.  Where would I find the source for CFNetwork for Windows?

[Mark Rowe (bdash)]

CFNetwork is used for HTTP support on both Mac and Windows.  The source for the version being used by Safari on Windows is not available at this time.

As Brady mentioned, ResourceHandleWin is not used.  It predates Apple's Windows port.  A quick glance suggests that is the only file that is currently unused in the network directory.

[David Kilzer (:ddkilzer)]

Dan, newer Safari for Windows seeds are available using info in Bug 14747 Comment #5.  Does this bug still occur in the latest seed?

[Dan Fabulich]

The bug appears to be fixed in Seed 310A15 for Windows.

[David Kilzer (:ddkilzer)]

(In reply to comment #6)
> The bug appears to be fixed in Seed 310A15 for Windows.

Marking bug as RESOLVED/FIXED.