- TO DO
- SOURCE AVAILABILITY
- COPYRIGHT AND LICENSE
HTTP::Cookies::Chrome - Cookie storage and management for Google Chrome
use HTTP::Cookies::Chrome; my $password = HTTP::Cookies::Chrome->get_from_gnome; my $cookie_jar = HTTP::Cookies::Chrome->new( chrome_safe_storage_password => $password, file => ..., autosave => ..., ); $cookie_jar->load( $path_to_cookies ); # otherwise same as HTTP::Cookies
This package overrides the
save() methods of
HTTP::Cookies so it can work with Google Chrome cookie files, which are SQLite databases. This also should work from Chrome clones, such as Brave.
First, you are allowed to create different profiles within Chrome, and each profile has its own set of files. The default profile is just
Default. Along with that, there are various clones with their own product names. The expected paths incorporate the product and profiles:
Starting with Chrome 80, cookie values may be (likely are) encrypted with a password that Chrome changes and stores somewhere. Additionally, each cookie record tracks several other fields. If you are using an earlier Chrome, you should use an older version of this module (the 1.x series).
- macOS - ~/Library/Application Support/PRODUCT/Chrome/PROFILE/Cookies
- Linux - ~/.config/PRODUCT/PROFILE/Cookies
- Windows - C:\Users\USER\AppData\Local\PRODUCT\User Data\$profile\Cookies
Try to retrieve the Chrome Safe Storage password by accessing the system secrets for the logged-in user. This returns nothing if it can't find it.
You don't need to use this to get the password.
On macOS, this looks in the Keyring using
On Linux, this uses
secret-tool, which you might have to install separately. Also, some early versions used the hard-coded password
peanut, and some others may have used
I don't know how to do this on Windows. If you know, send a pull request. That goes for other systems too.
guess_path( PROFILE )
Try to retrieve the directory that contains the Cookies file. If you don't specify
PROFILE, it uses
macOS: ~/Library/Application Support/Google/Chrome/PROFILE/Cookies
The extends the
newin HTTP::Cookies, with the additional parameter for the decryption password.
chrome_safe_storage_password - the password
This overrides the
loadfrom HTTP::Cookies. There are a few differences that matter.
The Cookies database for Chrome tracks many more things than HTTP::Cookies knows about, so this shoves everything into the "rest" hash. Notably:
Chrome sets the port to -1 if the cookie does not specify the port.
The value of the cookie is either the plaintext value or the decrypted value from
ignore_discardis set, this ignores the
$maxagepart of HTTP::Cookies, but remembers the value in
save( [ FILE ] )
With no argument, save the cookies to the original filename. With a file name argument, write the cookies to that filename. This will be a SQLite database.
set_cookiein HTTP::Cookies so it can ignore the port check. Chrome uses
-1as the port if the cookie did not specify a port. This version of
set_cookiedoes no port check.
You can get the Chrome Safe Storage password, although you may have to respond to other dialogs and features of its storage mechanism:
% security find-generic-password -a "Chrome" -w % security find-generic-password -a "Brave" -w
On Ubuntu using libsecret:
% secret-tool lookup xdg:schema chrome_libsecret_os_crypt_password application chrome % secret-tool lookup xdg:schema chrome_libsecret_os_crypt_password application brave
If you know of other methods, let me know.
Some useful information:
On Linux systems not using a keychain, the password might be
mock_password. Maybe I should use Passwd::Keyring::Gnome
creation_utc INTEGER NOT NULL UNIQUE PRIMARY KEY host_key TEXT NOT NULL name TEXT NOT NULL value TEXT NOT NULL path TEXT NOT NULL expires_utc INTEGER NOT NULL is_secure INTEGER NOT NULL is_httponly INTEGER NOT NULL last_access_utc INTEGER NOT NULL has_expires INTEGER NOT NULL is_persistent INTEGER NOT NULL priority INTEGER NOT NULL encrypted_value BLOB samesite INTEGER NOT NULL source_scheme INTEGER NOT NULL source_port INTEGER NOT NULL is_same_party INTEGER NOT NULL
There are many ways that this module can approve.
1. The HTTP::Cookies module was written a long time ago. We still inherit from it, but it might be time to completely dump it even if we keep the interface.
2. Some Windows people can fill in the Windows details for
3. As in (2), systems that aren't Linux or macOS can fill in their details.
4. We need a way to specify a new password to output the cookies to a different Chrome-like SQLite database. The easiest thing right now might be to make a completely new object with the new password and load cookies into it.
This module is in Github:
brian d foy,
Jon Orwant pointed out the problem with dates too far in the future
Copyright © 2009-2021, brian d foy <email@example.com>. All rights reserved.
This program is free software; you can redistribute it and/or modify it under the terms of the Artistic License 2.0.