HTML Imports: Send credentials for same origin requests

Source/core/fetch/CrossOriginAccessControl.cpp

 /*
  * Copyright (C) 2008 Apple Inc. All Rights Reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 222 matching lines @@
 
     // Same-origin request URLs that redirect are allowed without checking access.
     if (!securityOrigin->canRequest(originalURL)) {
         // Follow http://www.w3.org/TR/cors/#redirect-steps
         String errorDescription;
 
         // Steps 3 & 4 - check if scheme and other URL restrictions hold.
         bool allowRedirect = isLegalRedirectLocation(requestURL, errorDescription);
         if (allowRedirect) {
             // Step 5: perform resource sharing access check.
-            StoredCredentials withCredentials = resource->resourceRequest().allowStoredCredentials() ? AllowStoredCredentials : DoNotAllowStoredCredentials;
+            StoredCredentials withCredentials = resource->lastResourceRequest().allowStoredCredentials() ? AllowStoredCredentials : DoNotAllowStoredCredentials;

[Nate Chapin, 2014/03/18 21:50:20]

I would have thought that lastResourceRequest() was the same as the request
parameter. Is that incorrect?

[Hajime Morrita, 2014/03/18 22:10:40]

The |request| parameter isn't in the Resource::m_redirectChain yet so
lastResourceRequest() is different from |request|. It is added to the chain
later. Probably that is because handleRedirect() could decline the upcoming
redirect.

[Nate Chapin, 2014/03/18 22:15:44]

Maybe we should consider updating the redirect chain, then doing the
handleRedirect() check? Having the extra request in the redirect chain shouldn't
matter if the request gets cancelled.

We don't have to block this patch on that change, though.

[Hajime Morrita, 2014/03/18 22:34:58]

I can do this, but how does it help?
We need secondLastResouceRequest() or something here then, or example.

I agree that though, the redirect handling is confusing as a result of
historically accumulated debt and should be straighten somehow. Currently the
flow goes up and down between layers and hard to follow.

             allowRedirect = passesAccessControlCheck(redirectResponse, withCredentials, securityOrigin, errorDescription);
             if (allowRedirect) {
                 RefPtr<SecurityOrigin> originalOrigin = SecurityOrigin::create(originalURL);
                 // Step 6: if the request URL origin is not same origin as the original URL's,
                 // set the source origin to a globally unique identifier.
                 if (!originalOrigin->canRequest(requestURL)) {
                     options.securityOrigin = SecurityOrigin::createUnique();
                     securityOrigin = options.securityOrigin.get();
                 }
             }
@@ skipping 10 matching lines @@
         request.setHTTPOrigin(securityOrigin->toAtomicString());
         // If the user didn't request credentials in the first place, update our
         // state so we neither request them nor expect they must be allowed.
         if (options.credentialsRequested == ClientDidNotRequestCredentials)
             options.allowCredentials = DoNotAllowStoredCredentials;
     }
     return true;
 }
 
 } // namespace WebCore