Re: Suborigin update

> - document.cookie is necessary for applications to keep working without
> requiring users to sign into every part of your website separately.
> Security-wise it's on par with existing behavior (cookies being shared
> between subdomains) so we believe it's a reasonable default. That having
> been said, I wouldn't be surprised based on comments from Dev that we'll
> eventually want to build an opt-out to give a Suborigins a unique cookie
> jar.

Would a cookie set by top level domain be readable though? That's what
was I was really not ok with and that is also not par with current
sub-domain behavior.

Additionally, I like the current sub-domain behavior has been a
forever source of pain and so extending it doesn't sound like a great
idea.

I can understand this being a requirement though. I am just not a fan
of making it the default. Allowing it through some 'unsafe-cookie'
sort of opt-in (an opt-in we make mandatory in v1) seems more
reasonable to me.


> In the case of XHR/Fetch, our solution is to send a CORS preflight for all
> XHR/Fetch calls from a Suborigin, and we'll add a Suborigin header. Then
> we'll require that the response has an Access-Control-Allow-Suborigin header
> that lists the requesting Suborigin (or, alternatively, a '*' response to
> Access-Control-Allow-Origin).

This seems a big hammer. While secure, the perf impact of pre-flight
is terrible and applications go out of their way with some horrible
hacks to avoid it. At the least, why not inherit existing behavior:
preflight only for complex requests?

Also, how will * response work? Will the request be sent with a
cookie? Does the app set request.withCredentials to false? How would
the app know whether it is running in a browser with subOrigin support
and needs to set that flag?

> Importantly, the app
> will need to have the cookie because otherwise you'd stop being logged in
> and it would suck for usability.

I am still confused why the app needs document.cookie though. The
cookie is sent with the request.

~dev

Received on Saturday, 14 November 2015 21:26:59 UTC