~bptato/chawan#34: 
Persistent cookies support?

If I'm not mistaken, as of now, chawan doesn't store cookies between sessions (logins do not work between instances, and I also couldn't find a cookies storage file).

An option for that could certainly make the experience more versatile and consistent, what do you think?

Status
RESOLVED CLOSED
Submitter
~skejg
Assigned to
No-one
Submitted
a month ago
Updated
a month ago
Labels
No labels applied.

bptato a month ago · edit

~skejg wrote:

If I'm not mistaken, as of now, chawan doesn't store cookies between sessions (logins do not work between instances, and I also couldn't find a cookies storage file).

An option for that could certainly make the experience more versatile and consistent, what do you think?

Good that you ask, I've been thinking about this for some time. The planned design so far:

[external]
cookie-file = "cookie" # cookie file path

[[siteconf]]
host = 'example\.com'
# cookie = true remains the same as now (i.e. doesn't save cookies).
# instead, you can save them like:
cookie = "save" # enabled and saved to cookie-file
# (works in [buffer] too, to enable saving on all sites.)

[[siteconf]]
host = 'example\.org'
share-cookie-jar = 'example.com' # same cookie jar as example.com
third-party-cookie = 'example\.com' # allow Set-Cookie from example.com
# if two sites share a cookie jar, then their "cookie" values must
# match, or an error is displayed. e.g. here "save" must be set.
cookie = "save"

This is backwards compatible, and as a bonus it allows for read-only persistent cookies (because "cookie = true" still reads the cookie file.)

The part I'm struggling with is cookie-file's format. I was hoping to reuse an existing one, but neither Netscape (used by curl) nor w3m allow multiple cookie jars in the same file. And mainstream browsers have long given up and just dump everything in sqlite. So maybe we need a new format...

~skejg a month ago

~bptato wote:

The planned design so far [...]

That looks great! Indeed, no breaking changes in the slightest while at the same time offering new possibilities.

neither Netscape (used by curl) nor w3m allow multiple cookie jars in the same file

You mean multiple cookie jars for the same URL? But how would one chose between those then?

bptato a month ago · edit

You mean multiple cookie jars for the same URL? But how would one chose between those then?

It's the other way around. By default, every host has its own cookie jar.

Naturally, this breaks login mechanisms that require cookie sharing, hence the share-cookie-jar option.

~skejg a month ago*

Oh, I see. As a person, who only allows cookies for a very few selected hosts, simply didn't think about that. But, agreed, this is indeed a problem...

~bptato REPORTED CLOSED a month ago

Done in aa2e19429.

In the end, I've decided to go with curl's cookies.txt format despite its limitations, because it's at least vaguely compatible with other programs.

Cookie jar separation is implemented by prepending "jarname@" to the domain, but only if the domain is not the same as the cookie jar's name:

# cookie jar: a.example
a.example	FALSE	/	TRUE	1710846333	muffins	1234
# cookie jar: b.a.example
b.a.example	FALSE	/	TRUE	1710846333	muffins	1234
# cookie jar: a.example (but domain remains b.a.example)
a.example@b.a.example	FALSE	/	TRUE	1710846333	muffins	1234

So it's always backwards-compatible, and usually (but not always) forwards-compatible. In practice, most cookies are specified on the right domain, so this should rarely be an issue (and even then, it's easy to sed it out).

As a test, I've tried taking some cookies from Firefox using https://addons.mozilla.org/en-US/firefox/addon/export-cookies-txt/, and it seems to be working as expected after setting "cookie" and "share-cookie-jar" appropriately. (I recommend ticking "Prefix HttpOnly cookies" for better security.)

Register here or Log in to comment, or comment via email.