Verbosity / ease of use

[zcorpan]

The explainer demonstrates that somewhat complex cases are easier with this API (e.g. same-site comparisons), but for simple cases it seems this API is harder to use than the status quo.

Current:

addEventListener('message', e => {
  if (e.origin === "https://example.org") {
    // do something
  }
});

This API:

addEventListener('message', e => {
  if (Origin.parse(e.origin).isSameOrigin(Origin.parse("https://example.org"))) {
    // do something
  }
});

Maybe something like

addEventListener('message', e => {
  if (e.originObject.isSameOrigin("https://example.org")) {
    // do something
  }
});

[mikewest]

If e.origin was an Origin object, you could drop one = from your "Current" example, and string coercion would kick in. That is the following would work just fine:

addEventListener('message', e => {
  if (e.origin == "https://example.org") {
    // do something
  }
});

That seems pretty straightforward to me. That said, it might well be useful to find ways to make common checks simpler. A variant of isSameOrigin/isSameSite that accepts a string could certainly be reasonable if it turns out that's a path developers want to be walking down often.

[zcorpan]

Recommending == over === in security-sensitive code doesn't seem like sound advice. I guess you could stringify with String(), but I thought the point was to move away from working with strings. If the new code looks the same as currently, the next developer who wants to do same-site checks instead will solve it with regexp instead of switching isSameOrigin to isSameSite.

[mikewest]

Oh, of course. Ideally we wouldn't be doing string comparisons here at all because we'd find ways to represent things as Origin objects rather than serializations; I was simply reacting to the example you put together.

I think the postMessage() case will break down into a few categories:

1. Folks will want to talk to themselves, in which case they'd use the Origin we'll make accessible somehow on self and compare it to the origin we'll make accessible somehow on MessageEvent, e.g. e.originObj.isSameOrigin(self.originObj). That doesn't seem much more verbose than e.originObj === self.origin, and isSameOrigin(...) seems much clearer in purpose than ===.

2. Folks will want to talk to other pieces of their site, in which case they'd do the same thing with the same objects, with a broader method, e.g. e.originObj.isSameSite(self.originObj).

3. Folks will want to allowlist one or more specific origins or sites. This is the example you're pointing towards above, and I agree that it would be helpful to have some well-lit path. My feeling is that a simple version of this could be built relatively tersely:

   function isOriginTotallySafe(eventOrigin) {
     const curatedListOfOrigins = [
       "https://example.com",
       "https://site.example",
       ...
     ].map(o => new Origin(o));
     return curatedListOfOrigins.some(o => e.origin.isSameOrigin(o));
   }

   That said, I agree with what I hear you saying in my head: that's a lot of code to replace === in the very simplest case of a single expectation. If it's something we see developers getting hung up on, I'm confident we could find a way to handle the special, common case.

4. Folks will want more complicated matching still (e.g. subdomains of a certain pattern, but not everything on a site, etc). This could justify integration with URLPattern (either through an OriginPattern variant, or teaching URLPattern how to match Origins) might be a reasonable way of supporting complicated variants of this kind of comparison.

[mikewest]

@zcorpan: In whatwg/html#11846 (comment), you said:

I would like to see #6 addressed.

I'm not sure what you want to see addressed here. In the latest draft/PR, the common case for message listeners shifts from:

addEventListener('message', e => {
  if (e.origin === "https://example.org") {
    // do something
  }
});

to

addEventListener('message', e => {
  const senderOrigin = Origin.from(e);
  const acceptableOrigin = Origin.from("https://example.org/");
  if (senderOrigin.isSameOrigin(acceptableOrigin)) {
    // Or `Origin.from(e).isSameOrigin(Origin.from("https://example.org/"))`; from 35 to 64 characters.
  }
});

That is more verbose, I agree. But as I said above, I don't think it's too verbose, and I think the clarity of .isSameOrigin(...) over === is actually pretty valuable. This seems especially true given that === is an incomplete representation of "same originness" for opaque origins (which all serialize to "null"). It sounds like you might disagree with that evaluation: is there a shape or spelling that you'd prefer?

[annevk]

For the simple cases people can continue to use string comparisons as well. They are robust. This is primarily useful for opaque origins and isSameSite() comparisons.

[zcorpan]

I think adding e.originObject to MessageEvent and overloading isSameOrigin and isSameSite to accept Origin or string as input should reduce verbosity meaningfully.

[annevk]

Serialized sites don't exist though. And serialized origins don't have a corresponding parser. I think we should start out simple here until we are more confident about what is needed.

[zcorpan]

Serialized sites don't exist though.

Serialized origins exist. A string as input to isSameSite in my mind would implicitly call Origin.from().

A parser for origin is already defined in the PR for Origin.from(), overloading would just be a convenience.

[mikewest]

I think adding e.originObject to MessageEvent and

I'm a little skeptical of this, both because I don't like the name (🤪) and because Origin.from seemed like an elegant way of avoiding the need to have the attributes at all. If we do add it to MessageEvent, we'd probably want to add it to all the other objects that expose a serialized origin today. I'm not sure that's worth doing.

overloading isSameOrigin and isSameSite to accept Origin or string as input should reduce verbosity meaningfully.

Let's say we shifted both isSameOrigin and isSameSite to accept any values, and ran the from(...) steps on the input before executing the same origin/site check. This would allow us to drop one Origin.from call, shifting from:

Origin.from(e).isSameSite(Origin.from("https://a.com"))

to:

Origin.from(e).isSameSite("https://a.com")

I'm not sure how much precedent there is for this kind of approach (nor do I think it's necessary) but it doesn't seem crazy. I'd implement it if that's what we can agree on.

[annevk]

I guess there is some precedent with promises, but I'm a bit meh about it for an initial version. Rather keep things simple until we find out what it's used for.

[zcorpan]

OK, I guess we can start with simple-in-spec and revisit this when web developers complain that it's not sufficiently simple for them.