Clarify interaction with CORS (preflight requests) about beacon HOT 23 CLOSED

Do you always include credentials? Note that Fetch doesn't have such a flag (it's credentials mode these days). Fetch does have algorithms you could use to get bytes and a MIME type out of those data types for setting Content-Type and such.

from beacon.

Do you always include credentials?

Yes, see step 10 in http://w3c.github.io/beacon/#sec-processing-model.

Fetch does have algorithms you could use to get bytes and a MIME type out of those data types for setting Content-Type and such.

When and where are those invoked?

from beacon.

See https://fetch.spec.whatwg.org/#concept-bodyinit-extract which is used by both XMLHttpRequest and fetch() and should probably be used by Beacon too. Maybe at some point we should simply define the Beacon API directly in Fetch since it would only be a couple lines of text (the longlivedness applies to a number of features so that needs to become a more general feature in Fetch anyway).

from beacon.

Per 8/12 call, Ilya will follow-up. Assigning to him.

from beacon.

@annevk ptal: #11 - does that look sane? I think that should resolve this issue: the credentials mode is always set to include, and the update in pull relies on Fetch to extract to set the Content-Type.

from beacon.

You also want to change DOMString to USVString everywhere. And you want to accept ArrayBuffer in addition to ArrayBufferView. And you want to rely on IDL rather than "Typed Array" for their definitions. "Typed Array" is obsolete. However, once you start relying on Fetch, you might as well use https://fetch.spec.whatwg.org/#bodyinit, no? And thereby also accept URLSearchParams.

from beacon.

@annevk thanks, updated. PTAL.

from beacon.

@annevk @mikewest would appreciate a sanity check...

• sendBeacon is relying on Fetch (credentials mode: include, mode: cors).
  • passing in some content-types to it may trigger "non-simple" mode (extract bits here)
• we don't care* about the response.. well, almost. We do make the request with credentials flag and UA needs to process the Set-Cookie's, but otherwise there is no application callback.

Now say I'm running a popular collector that's used by many sites on the web:

• Some requests may trigger a preflight, so I need to handle OPTIONS requests.
• Due to credentials flag I can't return a ACAO:*.. I have to dynamically generate the opt-in header for each origin, and also emit a Access-Control-Allow-Credentials: true.

Is that right, am I missing anything? Is there any way to simplify this?

Current bar for img beacons is that you don't have to do any of the above, and requirement to handle OPTIONS requests + dynamic ACAO generation is adding a lot of complexity, especially if you're running at scale. I guess OPTIONS can be mitigated by sticking to from-encoded data, but we still have ACAO to deal with..

from beacon.

Reopening to make sure we followup on and address above question(s).

from beacon.

Per discussion at TPAC with @npdoty, follow up on whether Beacon-Age can be treated as a simple header by CORS as it is a User-Agent added header. Also, Beacon uses POST and the CORS/Fetch specs state that POST data must preflight unless is Form data.

from beacon.

Just because it is a user-agent-added header doesn't necessarily mean it can poke a hole in CORS. Unless the security teams signed off on yet another hole.

from beacon.

Discussion relevant to Beacon-Age: is happening on igrigorik/http-client-hints#68

from beacon.

To answer my own question in #10 (comment), put together a demo: http://output.jsbin.com/hacisa/latest/quiet. Here are the highlights:

• sendBeacon triggers a POST, which is a simple method.
• sendBeacon sets credentials mode to include.
• If the payload Content-Type meets simple header requirements (application/x-www-form-urlencoded, multipart/form-data, or text/plain), then sendBeacon request is a simple request that does not require CORS preflights.
• if the payload Content-Type is not one of the above types - e.g. if you pass in a Blob - then the browser will first trigger a CORS preflight, and if the server ACK's it, then we send the request.

Based on above, I think current spec is correct and doesn't require any modifications. If the developer needs to send a Blob, then they'll have to implement appropriate CORS bits... just as they would today if they wanted to XHR a Blob payload.

The other minor complication here is Beacon-Age. If the browser chooses to delay delivery, then appending Beacon-Age would trigger a CORS preflight check, because it's not a 'simple header'. That said, none of the current implements delay sendBeacon's, so one short-term solution here is to simply drop Beacon-Age from the spec. As I outlined in whatwg/fetch#184, I think this coalescing logic should live in Fetch.. and Fetch should set that header if/when request dispatch is delayed. Beacon would simply set a flag on fetch request to indicate that the request is allowed to be deferred.

• I think current Beacon spec behavior is sound and we can close this bug.
• I propose we drop Beacon-Age and move coalescing discussion to Fetch.
• I propose we rework the security + privacy sections to document above observations (that'll address #16 as well)

from beacon.

All that seems reasonable to me.

from beacon.

Makes total sense to me.

from beacon.

PTAL: #23.

from beacon.

Resolved via #23.

from beacon.

Is that right, am I missing anything? Is there any way to simplify this?

The way to simplify this would be to remove the CORS requirement that certain Content-Type values makes the Content-Type header a non-simple header. I.e. the way to simplify this would be to make Content-Type always be a simple header.

If that change was made, then sendBeacon would never trigger preflights.

If Blink makes that change then Gecko would follow suit.

But you should probably check with your security folks before making such a decision.

from beacon.

o_O, I really don't get your casualness around the same-origin policy. In one thread you're arguing we should special case Authorization and thereby make the handshake harder, and here you are suggesting to reopen a hole we plugged. (From what I remember, some servers accepting application/json payloads, do not anticipate cross-origin requests.)

from beacon.

Yes, there are lots of judgement calls when it comes to security. I don't think dealing in absolutes makes for a safer web. For example, simplicity is often quite valuable when it comes to keeping something safe.

One important thing to consider here is that Chrome has supported sending arbitrary payloads with arbitrary Content-Types for a long time. Google has been aware of it for almost a year and do not appear to be in a hurry to fix it. And to my knowledge no website has been compromised as a result.

Another thing that makes a difference here is that using Authorization headers to handle log-in credentials seems like good design. So something that we should not discourage sites from doing.

However using the Content-Type header as a security mechanism does not seem like a good reliable design. As is demonstrated by the fact that you're currently exposed due to Chrome's behavior. So it's something that I'm much happier to get rid of.

When we originally designed CORS, we also intentionally made the decision that it would now be possible to make Content-Type: text/plain and Content-Type: multipart/form-data requests where the request body does not follow those encoding schemes, thus possibly triggering new behaviors in servers. I think that was the right decision despite carrying some risk.

from beacon.

I didn't know Chrome violates Content-Type CORS semantics. @tyoshino, is that true?

from beacon.

https://bugs.chromium.org/p/chromium/issues/detail?id=490015

from beacon.

I see, only with beacons. Clear sign of a poorly layered network stack. :/

from beacon.