I can't confirm your analysis, but I just want to give you some background info;
Our team is currently working on a new http stack, that you can try
with the --new-http flag. Note that SSL support is a work in progress
so your tests will probably fail with this flag.
We are departing from WinHTTP. IE doesn't use WinHTTP, it uses WinINet
so don't expect similar behavior even without the --new-http flag. New
authentication digests will be implemented in the new stack. This will
take some time.
Please search the archives and the issues list to find out about the
current progress.
Thanks
M-A
2008/9/21 Hector <[EMAIL PROTECTED]>:
>
> Ok, tracing Chrome I narrowed it down to the 2nd possible Redirection
> "mite' explanation for the HTTP BASIC/Digest Authorization problem.
> This is in the function NotifyHeadersComplete() in:
>
> src\net\url_request\url_request_job.cc
>
> This function is called to do the final request preparation:
>
> void URLRequestJob::NotifyHeadersComplete() {
> .....
> if (IsRedirectResponse(&new_location, &http_status_code)) {
> ....
> } else if (NeedsAuth()) {
> scoped_refptr<net::AuthChallengeInfo> auth_info;
> GetAuthChallengeInfo(&auth_info);
> // Need to check for a NULL auth_info because the server may have
> failed
> // to send a challenge with the 401 response.
> if (auth_info) {
> scoped_refptr<net::AuthData> auth_data;
> GetCachedAuthData(*auth_info, &auth_data);
> if (auth_data) {
> SetAuth(auth_data->username, auth_data->password);
> return;
> }
> request_->delegate()->OnAuthRequired(request_, auth_info);
> // Wait for SetAuth or CancelAuth to be called.
> return;
> }
> }
> ...
> }
>
> What is it doing is completely bypassing the authorization check and
> adding of the "Authorization:" header if the request was a
> redirection. This is not correct. The authorization header MUST be
> added at this stage of the final header completion logic.
>
> Can someone confirm this debugging analysis?
>
> I am now going to see if can understand the source better here to see
> if can and simply make this parallel logic rather than an one or the
> other.
>
> Thanks
>
> ---
> HLS
>
>
> On Sep 21, 10:23 pm, Hector <[EMAIL PROTECTED]> wrote:
>> It appears Chrome is using the Microsoft API WinHTTP to perform BASIC
>> and DIGEST authentication.
>>
>> Assumption:
>>
>> If IE is using WinHTTP as well, I have no reason to believe IE is not,
>> and it works correctly, then Chrome should implement WinHTTP the same
>> way.
>>
>> Two Possible Issues To Explore
>>
>> 1) Faulty Cache Logic For Authorized Schemes
>>
>> Based on WinHTTP MSDN documentation
>>
>> http://msdn.microsoft.com/en-us/library/aa383144(VS.85,printer).aspx
>>
>> the implementer is responsible for caching authentication per url.
>> WinHTTP does not cache it.
>>
>> I believe Chrome caching logic is faulty here. I say that for two
>> reasons:
>>
>> 1.1) The test code semantics suggest that two urls:
>>
>> http://domain/folder/page.htm
>> http://domain/page.htm
>>
>> is under the same authorization scheme and realm, i.e.:
>>
>> http://domain/server_realm
>>
>> That suggest that both urls above (as well as others under http:/
>> domain) are authorized under the same realm and user credentials.
>>
>> 1.2) The auth_scheme string prepared in the net/http code does use:
>>
>> http://domain/server_realm
>>
>> 2) Possible Redirection Flaw
>>
>> The other possibility is that Chrome redirection logic is not taken
>> into account whether the referrer was authorized.
>>
>> This is an angle I am going to look at now.
>>
>> Comments?
>>
>> PS: Ideally, if there is an assigned cog for the net/http logic, I
>> really hope he can chime in here and provide input. I, like anyone
>> else here, don't wish to going nuts posting notes galore pissing off
>> people and losing my welcome here. Thats not me, however, I do wish
>> to address this asap. Thanks.
>>
>> --
>> HLS
>>
>> On Sep 21, 9:06 pm, Hector <[EMAIL PROTECTED]> wrote:
>>
>> > Folks,
>>
>> > The main reason for me to get the chrome source was to look at the
>> > long time problem that Safari had with HTTP BASIC/DIGEST
>> > authentication which obviously Chrome has inherited.
>>
>> > With our developers and operators, who were getting increasingly
>> > frustrated with this problem as th "Apple Clones" era was moving into
>> > the Windows environments, the general agreement was that the problem
>> > was with WebKit since they both using the same rendering engine.
>>
>> > Attempting to seek input from Apple and now the Chrome team was not
>> > getting anywhere so getting the source and seeing whats going on had
>> > to be done.
>>
>> > Well, not I am not too such it is a WebKit issue because last night I
>> > downloaded yet another webkit based browser - Arora and it worked
>> > fine.
>>
>> > So there has to be something with the way Safari (and Chrome inherits)
>> > has implemented their authentication cache.
>>
>> > I would like to get a serious discussion on this long time problem.
>> > I would like for someone to point me to the code snippets I should
>> > look for regarding how the engine resolves authenticated vs non-
>> > authenticated requests.
>>
>> > Overall the issue is, a user request
>>
>> > http://domain--> redirection tohttp://domain/public/default.htm
>>
>> > where a login button are available.
>>
>> > [ LOGIN ] ---> http://domain/login?mode=html
>>
>> > When clicked, this does a www-authenticate 401 response forcing the
>> > browser to popup its internal authentication box for BASIC or DIGEST
>> > authentication.
>>
>> > When the users fills it in, and clicks ok, the server then logs in the
>> > user and redirects him to:
>>
>> > http://domain
>>
>> > which NORMAL browsers will perform the redirected request with the
>> > Authorization: header included and the server will finally output he
>> > privatehttp://domain/default.htmhomepage.
>>
>> > What happens is Safari/Chrome, is that it does not send the
>> > authorization header and the server redirects him back to /public/
>> > default.htm.
>>
>> > No other browsers other than Safari/Chrome exhibit this behavior.
>>
>> > We explored having the server redirecting to /default.htm and this
>> > works to display the right page, but looking at the socket logs, shows
>> > there are TWO request done for every page browsed from that point one
>> > - one without the Authorization header which the server response with
>> > 401 and then again with the Authorization.
>>
>> > So this is something I would like to resolved.
>>
>> > The other things I want to resolve are:
>>
>> > At the operation level:
>>
>> > - Better handling of MIME based file association and launching.
>>
>> > At the security level:
>>
>> > - Add Allow | Allow Session | Block dialog/manager for cookies.
>> > - Option to turn off some of the "spying" stuff.
>>
>> > The main things for me is the HTTP AUTH and the File Association
>> > issue, these are show stoppers for Chrome usage for our customers.
>>
>> > --
>> > HLS
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
