Comments (14)
#4 is somewhat related.
When I was sketching a similar design (w3c/ServiceWorker#707 (comment)) I couldn't settle on "match" or "get". "get" doesn't map well.
WIth the singular get/match, "name" is required, it doesn't make sense otherwise. With getAll/matchAll the name is optional. It feels like the APIs should reflect that. Eg:
navigator.cookies.match(name, { path });
navigator.cookies.matchAll({ name, path });
In the singular match, I'm not sure what the default path should be, maybe it should be required too.
Additionally I can't decide if "path" should be treating the path as a key, or a scope. Eg:
navigator.cookies.matchAll({
path: someRequest.url
});
Should the above return me all cookies with their path set to someRequest.url
, or should it return me all the JS-visible cookies that would be sent along with a request to someRequest.url
?
from cookie-store.
I think trying to fit this into a map-like shape is confusing things.
Maybe it should be simpler?
getAll
- takes no arguments, returns all the cookies for the domain. This means you can get multiple entries with the same name but different paths. Filtering is left to the developer.
I think the defaults and path stuff are too confusing in the get
method, so maybe we shouldn't have one.
forURL(url)
- returns the JS-visible cookies that would be sent along with a request to url
. url
could default to the client url, making forURL()
return the same set of cookies as document.cookie
. "name" would be unique in the returned cookies, so it could be a map.
from cookie-store.
returns all the cookies for the domain
Hmm, I guess it should only be "cookies for this origin and parent origins". Exposing cookies targeted to other subdomains would be bad.
from cookie-store.
Exposing paths and/or domains is new information not currently visible on
the web. Cookie:/reading document.cookie does not tell you the path or
domain, only the name and value.
Allowing the path to be specified seems OK, but I think requiring it is
odd, at least in document contexts. I think it should default to the path
of the current page.
On Mar 9, 2016 04:45, "Jake Archibald" [email protected] wrote:
returns all the cookies for the domain
Hmm, I guess it should only be "cookies for this origin and parent
origins". Exposing cookies targeted to other subdomains would be bad.—
Reply to this email directly or view it on GitHub
#10 (comment)
.
from cookie-store.
(Also, specifying a read path just means you get back all cookies in-scope
at that path, including those set at parent paths.)
On Mar 9, 2016 06:09, "Ben Wiley Sittler" [email protected] wrote:
Exposing paths and/or domains is new information not currently visible on
the web. Cookie:/reading document.cookie does not tell you the path or
domain, only the name and value.Allowing the path to be specified seems OK, but I think requiring it is
odd, at least in document contexts. I think it should default to the path
of the current page.
On Mar 9, 2016 04:45, "Jake Archibald" [email protected] wrote:returns all the cookies for the domain
Hmm, I guess it should only be "cookies for this origin and parent
origins". Exposing cookies targeted to other subdomains would be bad.—
Reply to this email directly or view it on GitHub
#10 (comment)
.
from cookie-store.
Exposing paths and/or domains is new information not currently visible on the web. Cookie:/reading document.cookie does not tell you the path or domain, only the name and value.
Right, but should we carry on that tradition? I can work out the path of cookies by loading an iframe and brute forcing the url & seeing how document.cookie
changes.
Allowing the path to be specified seems OK, but I think requiring it is odd, at least in document contexts. I think it should default to the path of the current page.
If you can specify the path, you make the above hack even easier.
(Also, specifying a read path just means you get back all cookies in-scope
at that path, including those set at parent paths.)
I don't disagree with that behaviour, but it makes this very un-map-like. The meaning of "path" in get/set becomes quite different.
from cookie-store.
My only intent when including a path argument was to allow a ServiceWorker to see script-visible cookies which would be in-scope for a given Fetch interception.
from cookie-store.
Yep, it's a good use-case
from cookie-store.
"name" would be unique in the returned cookies, so it could be a map.
No it wouldn't. TIL multiple cookies of the same name are sent in this case.
from cookie-store.
Right, but should we carry on that tradition?
I think we have to, otherwise this API is useless. The original point of this API was to allow people to manage cross-site logins in their service workers.
from cookie-store.
@domenic I was referring to exposing the path of a cookie. Discussion split off into #11
from cookie-store.
I've attempted to address this issue in the explainer (where path is called 'url' instead). Please take a look there and let me know what you think.
In particular, I think the IFRAME-based brute-forcing is preventable by a server rigorously sending X-FRAME-OPTIONS: DENY provided the user isn't tricked into allowing a pop-up. What do you think?
from cookie-store.
Fixed explainer link
from cookie-store.
Polyfill for document contexts and explainer are synced now on this issue. Re-open if you think the path restrictions are problematic (and explain why, please!)
from cookie-store.
Related Issues (20)
- Add references to secure/insecure contexts/origins and clarify the case of local files. HOT 3
- Add character set and length restrictions from RFC6265bis HOT 1
- Disallow setting cookie names that contain '='
- Fix up encoding definitions/references HOT 1
- Allow tab characters in cookies
- Consider using DOMHighResTimestamp instead of DOMTimeStamp HOT 8
- Interoperability with `document.cookie` when all cookies are blocked HOT 2
- Change get() to return null instead of undefined HOT 5
- cookieStore throws instead of returning rejected Promise HOT 4
- Add note about duplicate cookies
- Tuple syntax no longer allows / to be used HOT 2
- Path is UTF-8-encoded? HOT 1
- Event should only run on other tabs HOT 1
- Can a CookieChangeEvent changed array contain multiple CookieListItem of the same cookie?
- "path is not null" but path is not nullable HOT 2
- Domain attribute validation
- A question about "immediately evicted" in cookie change event documentation HOT 5
- Cookie event batching and firing HOT 5
- Domain Attribute Validation, Departure from RFC6265bis HOT 14
- Specify the behavior of `CookieStoreManager.subscribe()` when url of subscription is not provided HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cookie-store.