On Wed, Jul 7, 2010 at 1:28 AM, Anne van Kesteren <ann...@opera.com> wrote:
> On Fri, 02 Jul 2010 23:05:41 +0200, Charlie Reis <cr...@chromium.org> > wrote: > >> Hi all-- >> I'm trying to understand one of the example use cases in the CORS >> specification and how the various rules about credentials apply, and I'm >> wondering whether there's an issue to resolve. >> >> In the "Not tainting the canvas element" example at >> http://dev.w3.org/2006/waf/access-control/#use-cases, it looks like the >> images will be requested from http://narwhalart.example using <img> tags. >> If so, it's possible the user agent will send cookies on the GET request >> for the images. >> >> If I understand correctly, that implies that the HTTP response would have >> to include "Access-Control-Allow-Credentials: true," because cookies are >> considered credentials. However, I also see that providing >> "Access-Control-Allow-Credentials: true" means that * cannot be used for >> Access-Control-Allow-Origin. The use case mentions that the server could >> make the images accessible to all origins, though. >> > > Right. The server would have to know the origin of the request for that to > work given the current constraints in the CORS specification. The current > constraints are there as at least one implementor was afraid it would > otherwise be to easy to configure the server in such a way as to reveal > confidential information. > > > > Is the server allowed to omit the Access-Control-Allow-Credentials header >> and use * for Access-Control-Allow-Origin, despite the presence of cookies >> on the image's GET request? >> > > Not per CORS. In theory HTML5 could phrase the requirements around <img> > fetching to be different, but that does not seem like a good idea. > > > > Also, what is the reason that * is not allowed for responses that allow >> credentials? I've seen it documented in several places, but I'm not sure >> why that's the case. In cases like images or perhaps web fonts, it seems >> impractical to prevent credentials from being sent (unlike >> XmlHttpRequests). >> > > See above. > > > > On a similar note, are the image's GET requests required to carry Origin >> HTTP headers? >> > > They are required to carry an Origin header but the current requirements > also indicate that the header will just give "null" rather than an origin. > > That's unfortunate-- at least for now, that prevents servers from echoing the origin in the Access-Control-Allow-Origin header, so servers cannot host "public" images that don't taint canvases. The same problem likely exists for other types of requests that might adopt CORS, like fonts, etc. > I believe the plan is to change HTML5 once CORS is somewhat more stable and > use it for various pieces of infrastructure there. At that point we can > change <img> to transmit an Origin header with an origin. We could also > decide to change CORS and allow the combination of * and the credentials > flag being true. I think * is not too different from echoing back the value > of a header. > > I would second the proposal to allow * with credentials. It seems roughly equivalent to echoing back the Origin header, and it would allow CORS to work on images and other types of requests without changes to HTML5. Thanks, Charlie
