Skip to content

cookie 🍪 conundrum #146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
dylan1951 opened this issue Feb 14, 2025 · 3 comments · May be fixed by #161
Open

cookie 🍪 conundrum #146

dylan1951 opened this issue Feb 14, 2025 · 3 comments · May be fixed by #161
Assignees
@Codetrauma

Comments

@dylan1951
Copy link
Contributor

dylan1951 commented Feb 14, 2025 •
edited
Loading

The cookie situation seems quite messy.

Firstly is there a reason why we don't use the chrome.cookies API instead of saving them from request listeners?

Anyways here is the situation:

The signature of the following setCookies() function implies that it will be saved in the sublevel corresponding to the host - not the URL.

tlsn-extension/src/entries/Background/db.ts

Lines 333 to 338 in 1c9f340

export async function setCookies(host: string, name: string, value: string) {
return mutex.runExclusive(async () => {
await cookiesDb.sublevel(host).put(name, value);
return true;
});
}

However, currently the full URL is passed to setCookies

tlsn-extension/src/entries/Background/handlers.ts

Line 30 in 1c9f340

setCookies(link, cookieName, cookieValue);

To compensate for this, the rather confusing functiongetCookiesByHost() takes a full URL and returns the cookies for the first URL it finds in the cookiesDb where the given host matches.

tlsn-extension/src/entries/Background/db.ts

Lines 356 to 376 in 1c9f340

export async function getCookiesByHost(link: string) {
const ret: { [key: string]: string } = {};
const links: { [k: string]: boolean } = {};
const url = urlify(link);
for await (const sublevel of cookiesDb.keys({ keyEncoding: 'utf8' })) {
const l = sublevel.split('!')[1];
links[l] = true;
}
const cookieLink = url
? Object.keys(links).filter((l) => minimatch(l, link))[0]
: Object.keys(links).filter((l) => urlify(l)?.host === link)[0];
if (!cookieLink) return ret;
for await (const [key, value] of cookiesDb.sublevel(cookieLink).iterator()) {
ret[key] = value;
}
return ret;
}

Aside from being confusing and complicated, this approach actually doesn't work at all for some use cases, for example:

  1. Navigate to https://example.com
  2. Cookies are saved to the https://example.com sublevel
  3. Login at https://example.com/login
  4. Get redirected to https://example.com/profile
  5. getCookiesByHost('example.com) will NOT return the auth cookie because it will return the cookies that were associated with only the URL https://example.com before you authenticated (the first match).

This includes my use case, so I'm currently blocked.

Anyways I don't think it makes any sense at all to associate cookies with URL's. It should be per domain.
@dylan1951
Copy link
Contributor Author

If you guys are busy I can make a PR but I'll wait to hear your thoughts first

@dylan1951
Copy link
Contributor Author 

- setCookies(link, cookieName, cookieValue); 
+ setCookies(origin, cookieName, cookieValue);

This seems to work for my use case at least - so I'm unblocked. Would probably be best to tidy everything up properly though.

@dylan1951
Copy link
Contributor Author

Actually the example I gave can work if you use the glob pattern "https://example.com/profile". But it still doesn't work when the URL contains an ephemeral session token path parameter like https://example.com/profile/98109G9NENO3/.

In this case, if you use the glob pattern getCookiesByHost("https://example.com/profile/**") it will find the lexicographically first match. So, if you try to notarise using the plugin a second-time (different session token), it will return the cookies associated with whichever session was lexicographically first.

@heeckhau heeckhau assigned Codetrauma and unassigned 0xtsukino Mar 12, 2025
@Codetrauma Codetrauma linked a pull request Mar 26, 2025 that will close this issue
Retrieve latest headers and cookies #161
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Codetrauma Codetrauma

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Retrieve latest headers and cookies tlsnotary/tlsn-extension
3 participants
@dylan1951 @0xtsukino @Codetrauma