search

Room-Elephant / extension-chrome-key-retriever

Boost your web development productivity with this feature-rich extension. Gain complete visibility into the session, local, and cookie storage keys of your websites. Explore advanced functionalities like modifying these storage values and monitoring keys and sub keys effortlessly.
https://key-retriever.room-elephant.com/
Apache License 2.0
11 stars 2 forks source link

add domain to add item #103

Open JPedroBorges opened 1 year ago

JPedroBorges commented 1 year ago

Add domain field when creating a new cookie item.

Important

GET

If there are multiples match to a key, it will select based on the order that the browser sent it. This is not a new behavior, but would be interesting to figure out how is the order affected.

SET

Retrieves information about a single cookie. If more than one cookie of the same name exists for the given URL, the one with the longest path will be returned. For cookies with the same path length, the cookie with the earliest creation time will be returned. https://developer.chrome.com/docs/extensions/reference/cookies/#method-get

What this is actually saying is even if we request a cookie for a subdomain (subdomain.domain.com) if there are collisions with a same name cookie in the domain (domain.com) it will pick the most recent.

I'm unsure if we should retrieve all the cookies and select the correct subdomain cookie, or if this is a non issue.

Should we dig deeper?

screenshots

create page

image

view page

image

bmg13 commented 1 year ago

What this is actually saying is even if we request a cookie for a subdomain (subdomain.domain.com) if there are collisions with a same name cookie in the domain (domain.com) it will pick the most recent.

Would in any scenario the most recent not be the one you would want?

JPedroBorges commented 12 months ago

@Marianarodrigues7

we assume the cookie domain is the same as the current tab.

Yes, on the initial implementation of the cookie flow, we were just looking at cookies from top level domain of the current tab. I understand that this might be a bit limiting since we are excluding the “cross-domain cookies” as we often see in advertisement cookies. Do you foresee the need of including those as well? I'm unsure how feasible it is to do.

image

we don't see/have this information in our badges

Assuming that we are not working with cookies outside of the top level domain, the cookie will be applied to the current domain. This means, whatever you are on localhost or, domain.com you are still able to use the same entry for both situations. The whole point of the new domain field, was to control where the cookie was stored. image In this scenario, we have the same key being set on different domain levels. And the point of this change is for the user to be able to choose which one he wants to see. Maybe we could “lock” the top level domain, and give the ability for the user to choose only the subdomain? “Maintaining the consistency between tabs”?

@bmg13

Would in any scenario the most recent not be the one you would want?

This is something that I'm really struggling with. I'm not going to bite the bullet, I'm changing the implementation to list all cookies and pick the one that is correct instead of relying on chrome cookies API.

Furthermore, contrary to my beliefs that domains always started with . to be retro compatible with older browsers, I've found some examples where this is not true for the same key. image Not sure if this is an edge case or a specific framework. Either way, since the domain are different we have 2 entries in the cookies list. I really think there's a need to dig deeper into cookies before moving forward with this PR.

JPedroBorges commented 11 months ago

Due to a lack of direction on this topic, I'm removing the input field. Focusing on https://github.com/Room-Elephant/extension-chrome-key-retriever/issues/92 and on a later date, we can come back to this topic with a fresh eyes.