Specify session scope matching more precisely #156
Conversation
|
Actually I'm not sure I like this. We do a lot of registrable domain checks, which depend on port. So we need the port matching as well. Let me rework this one. |
|
Hm no maybe I was right the first time. For an origin-scoped session, the domain patterns don't matter. For a site-scoped session, cookies are included across ports, so the only question is whether site owners would want a session on the site The use of that seems much more limited than the use of host matching. To support that I think it's better to put the structure in the JSON schema rather than making the |
drubery
force-pushed
the
push-ulxvtvsqxtxp
branch
from
8f32491 to
ab4b570
Compare
drubery
force-pushed
the
push-unopzpqo
branch
2 times, most recently
from
0152f39 to
f0559d9
Compare
spec.bs
Outdated
| @@ -485,6 +484,7 @@ The <dfn>session credential</dfn> is a [=struct=] with the following | |||
| 1. |refresh URL| must be same-site with |destination|. | |||
| 1. If the value of the key "scope.include_site" in |response| is true: | |||
| 1. Let |destination site| be the [=host/registrable domain=] of |destination|. | |||
| 1. If |origin| is not equal to |destination site|, return. | |||
There was a problem hiding this comment.
I think we need to clarify this is origin's host we're comparing the destination site to.
Also: perhaps we should avoid using the word "site" when we're describing the eTLD+1 (i.e. not call it "destination site")? Since a site includes both the eTLD+1 and the scheme.
There was a problem hiding this comment.
Yeah I think we've been pretty sloppy with site vs domain, since DBSC is HTTPS-only today. Let me go through all of our uses of registrable domain in a separate PR.
| @@ -309,20 +308,20 @@ The <dfn>session credential</dfn> is a [=struct=] with the following | |||
| 1. |URL|'s [=url/path=] is exactly |path pattern|. | |||
| 1. |path pattern| ends in '/' and |URL|'s [=url/path=] starts with |path pattern|. | |||
| 1. |URL|'s [=url/path=] starts with |path pattern| followed by a '/'. | |||
| 1. If the |URL| matches the |session|'s [=refresh URL=], return "exclude". | |||
| 1. Return "include". | |||
| </div> | |||
|
|
|||
| ## Identify if a host matches a pattern ## {#algo-host-pattern-matches} | |||
There was a problem hiding this comment.
Just to check my understanding: Someone could have a pattern that's *.com, and that's okay because we already check that the URL is either same-site or same-origin with the scope origin (depending on include_site's value).
There was a problem hiding this comment.
Yes I think that's true today. If we combine include_site into the scope rules, then we'll need to be more careful here. (Maybe we just leave the same-site checks in place, and let the matching work unchanged?)
The specification for host matching is less powerful than currently implemented in Chrome. Chrome seems unspecified, but described [here](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md#proxy-bypass-rules). I don't think we want the full power described in that document for DBSC though. The current specification covers the expected key use cases. Host matching will be reused for `allowed_request_initiators` in a subsequent PR, so it's broken out into its own algorithm.
* Specify session scope matching more precisely The specification for host matching is less powerful than currently implemented in Chrome. Chrome seems unspecified, but described [here](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md#proxy-bypass-rules). I don't think we want the full power described in that document for DBSC though. The current specification covers the expected key use cases. Host matching will be reused for `allowed_request_initiators` in a subsequent PR, so it's broken out into its own algorithm. * Address comments --------- Co-authored-by: Daniel Rubery <drubery@chromium.org>
* Specify session scope matching more precisely The specification for host matching is less powerful than currently implemented in Chrome. Chrome seems unspecified, but described [here](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md#proxy-bypass-rules). I don't think we want the full power described in that document for DBSC though. The current specification covers the expected key use cases. Host matching will be reused for `allowed_request_initiators` in a subsequent PR, so it's broken out into its own algorithm. * Address comments --------- Co-authored-by: Daniel Rubery <drubery@chromium.org>
SHA: ad79474 Reason: push, by drubery Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
The specification for host matching is less powerful than currently implemented in Chrome. Chrome seems unspecified, but described here. I don't think we want the full power described in that document for DBSC though. The current specification covers the expected key use cases.
Host matching will be reused for
allowed_request_initiatorsin a subsequent PR, so it's broken out into its own algorithm.