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
-~----------~----~----~----~------~----~------~--~---
