Re: [suborigins] serializing of origins

Jochem, are you not happy more with the specific syntax or the general idea
of extending the origin string?

Separate origin/suborigin attributes in the MessageEvent object are
workable, but seem like a little bit more when converting legacy code
compared to the existing solution.



On Tue, Apr 11, 2017 at 12:00 PM, Mike West <mkwst@google.com> wrote:

> +Dev, who I hope will have informed opinions about how Dropbox would like
> to be using suborigins.
>
> I think getting rid of the serialization change would be a win. The new
> scheme has caused some weirdness in Blink's implementation, especially its
> integration with other layers of the system that shouldn't really need to
> know anything about suborigins.
>
> Dev will correct me, I hope, but AFAIK the goal of the serialization
> scheme is to ensure that applications that are not suborigin-aware fail
> closed when a suborigin tries to talk to them. That is, when `
> https://example.com/` <https://example.com/> with a suborigin of `foo`
> tries to `postMessage()` to another page on `https://example.com/`
> <https://example.com/>, then simply checking the message's `origin`
> attribute against `https://example.com/` <https://example.com/> should
> fail. Likewise for `origin` header checks.
>
> Another approach to those two cases would be what you suggest at the end
> of your email: set the `origin` attribute of a `MessageEvent` from a
> suborigin to `null` (not the string "null", but the object `null`), and add
> more attributes to allow folks to do reasonable comparisons. It strikes me
> that the `initiator` property you're suggesting might also be an
> opportunity to stuff the `domain` into the `MessageEvent`, which might be
> independently valuable. Hrm.
>
> For the `Origin` header, it seems like we're already failing closed if
> `Access-Control-Allow-Suborigin` isn't present in the response, right? If
> that's the case, then why not add a `Suborigin` header to the request? (I
> think this is basically what issue 11 in the spec is suggesting).
>
> -mike
>
> On Fri, Apr 7, 2017 at 10:11 AM, Jochen Eisinger <eisinger@google.com>
> wrote:
>
>> Hey all,
>>
>> I started to look at our suborigin implementation in blink, and one of
>> the things I was stumbling over was the serialization of an origin with a
>> suborigin, i.e. (scheme, host, port, suborigin) getting serialized to
>> ${scheme}-so://${suborigin}.${host}:${port}/
>>
>> It seems that the main reason for doing this is to break postMessage for
>> code that is not aware of suborigins. Is that the case?
>>
>> If that was the case, have we considered other ways to break this, e.g.
>> make origin return the null value and add instead a new property to message
>> (e.g. initiator with two properties origin and suborigin)?
>>
>> best
>> -jochen
>>
>
>