beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 07:30:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Libraries/LibWebView/CookieJar.h

133 lines
4.1 KiB
C
Raw Normal View History

Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
/*
LibWebView: Convert trivial ByteString uses to StringView in CookieJar
2024-01-26 15:47:57 +00:00
* Copyright (c) 2021-2024, Tim Flynn <trflynn89@serenityos.org>
Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
*/
#pragma once
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 16:56:22 +00:00
#include <AK/Function.h>
Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
#include <AK/HashMap.h>
#include <AK/Optional.h>
LibWebView: Port the CookieJar to String
2024-01-26 16:39:00 +00:00
#include <AK/String.h>
LibWebView: Convert trivial ByteString uses to StringView in CookieJar
2024-01-26 15:47:57 +00:00
#include <AK/StringView.h>
Browser: Add support for CookieJar to run in a transient, in-memory mode This is to allow running Ladybird without the SQL database for testing. Primarily, this will let us set 'follow-fork-mode' to 'child' within GDB to enter the WebContent process, rather than the SQLServer process. But this is also handy for digging into cookie storage issues.
2023-04-20 18:22:40 +00:00
#include <AK/Traits.h>
Browser: Process Max-Age cookie attribute Note: the default expiry time should be the "the latest representable date". However, DateTime::from_timestamp(NumericLimits<time_t>::max()) isn't feasible due to the for-loops in LibC's time_to_tm. So instead, this just sets the date to the maxium year.
2021-04-12 03:40:49 +00:00
#include <LibCore/DateTime.h>
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
#include <LibCore/Timer.h>
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 03:22:27 +00:00
#include <LibURL/Forward.h>
Browser+LibWeb: Move the cookie structure into LibWeb
2021-04-13 21:01:20 +00:00
#include <LibWeb/Cookie/Cookie.h>
Browser+LibWeb: Move cookie parser into LibWeb This moves the cookie parsing steps out of CookieJar into their own file inside LibWeb. It makes sense for the cookie structures to be in LibWeb for a couple reasons: 1. There are some steps in the spec that will need to partially happen from LibWeb, such as the HttpOnly attribute. 2. Parsing the cookie string will be safer if it happens in the OOP tab rather than the main Browser process. Then if the parser blows up due to a malformed cookie, only that tab will be affected. 3. Cookies in general are a Web concept not specific to a browser.
2021-04-13 20:47:05 +00:00
#include <LibWeb/Forward.h>
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 20:34:32 +00:00
#include <LibWebView/Database.h>
Ladybird+LibWebView: Move CookieJar, Database, and History to LibWebView These classes are used as-is in all chromes. Move them to LibWebView so that non-Serenity chromes don't have to awkwardly reach into its headers and sources.
2023-08-31 11:07:07 +00:00
#include <LibWebView/Forward.h>
Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
Ladybird+LibWebView: Move CookieJar, Database, and History to LibWebView These classes are used as-is in all chromes. Move them to LibWebView so that non-Serenity chromes don't have to awkwardly reach into its headers and sources.
2023-08-31 11:07:07 +00:00
namespace WebView {
Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
Browser: Add support for CookieJar to run in a transient, in-memory mode This is to allow running Ladybird without the SQL database for testing. Primarily, this will let us set 'follow-fork-mode' to 'child' within GDB to enter the WebContent process, rather than the SQLServer process. But this is also handy for digging into cookie storage issues.
2023-04-20 18:22:40 +00:00
struct CookieStorageKey {
bool operator==(CookieStorageKey const&) const = default;
LibWebView: Port the CookieJar to String
2024-01-26 16:39:00 +00:00
String name;
String domain;
String path;
Browser: Add support for CookieJar to run in a transient, in-memory mode This is to allow running Ladybird without the SQL database for testing. Primarily, this will let us set 'follow-fork-mode' to 'child' within GDB to enter the WebContent process, rather than the SQLServer process. But this is also handy for digging into cookie storage issues.
2023-04-20 18:22:40 +00:00
};
Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
class CookieJar {
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 16:56:22 +00:00
struct Statements {
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 20:34:32 +00:00
Database::StatementID insert_cookie { 0 };
Database::StatementID expire_cookie { 0 };
Database::StatementID select_all_cookies { 0 };
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 16:56:22 +00:00
};
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
class TransientStorage {
public:
using Cookies = HashMap<CookieStorageKey, Web::Cookie::Cookie>;
void set_cookies(Cookies);
void set_cookie(CookieStorageKey, Web::Cookie::Cookie);
Optional<Web::Cookie::Cookie> get_cookie(CookieStorageKey const&);
size_t size() const { return m_cookies.size(); }
LibWeb+LibWebView: Add an internal API to expire cookies with an offset Cookies have a minimum expiry resolution of 1 second. So to test cookie expiration, the test had to idle for at least a second, which is quite a noticeable delay now that LibWeb tests are parallelized. Instead, we can add an internal API to expire cookies with a time offset to avoid this idle delay.
2024-10-13 12:56:46 +00:00
UnixDateTime purge_expired_cookies(Optional<AK::Duration> offset = {});
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 20:34:32 +00:00
auto take_dirty_cookies() { return move(m_dirty_cookies); }
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
template<typename Callback>
void for_each_cookie(Callback callback)
{
LibWeb+LibWebView: Implement the latest cookie draft RFC We currently implement the official cookie RFC, which was last updated in 2011. Unfortunately, web reality conflicts with the RFC. For example, all of the major browsers allow nameless cookies, which the RFC forbids. There has since been draft versions of the RFC published to address such issues. This patch implements the latest draft. Major differences include: * Allowing nameless or valueless (but not both) cookies * Formal cookie length limits * Formal same-site rules (not fully implemented here) * More rules around cookie domains
2024-09-16 19:20:01 +00:00
using ReturnType = InvokeResult<Callback, Web::Cookie::Cookie&>;
for (auto& it : m_cookies) {
if constexpr (IsSame<ReturnType, IterationDecision>) {
if (callback(it.value) == IterationDecision::Break)
return;
} else {
static_assert(IsSame<ReturnType, void>);
callback(it.value);
}
}
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
}
private:
Cookies m_cookies;
LibWebView: Replace usage of LibSQL with sqlite3 This makes WebView::Database wrap around sqlite3 instead of LibSQL. The effect on outside callers is pretty minimal. The main consequences are: 1. We must ensure the Cookie table exists before preparing any SQL statements involving that table. 2. We can use an INSERT OR REPLACE statement instead of separate INSERT and UPDATE statements.
2024-06-04 20:34:32 +00:00
Cookies m_dirty_cookies;
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
};
Browser: Add support for CookieJar to run in a transient, in-memory mode This is to allow running Ladybird without the SQL database for testing. Primarily, this will let us set 'follow-fork-mode' to 'child' within GDB to enter the WebContent process, rather than the SQLServer process. But this is also handy for digging into cookie storage issues.
2023-04-20 18:22:40 +00:00
struct PersistedStorage {
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
void insert_cookie(Web::Cookie::Cookie const& cookie);
TransientStorage::Cookies select_all_cookies();
Browser: Add support for CookieJar to run in a transient, in-memory mode This is to allow running Ladybird without the SQL database for testing. Primarily, this will let us set 'follow-fork-mode' to 'child' within GDB to enter the WebContent process, rather than the SQLServer process. But this is also handy for digging into cookie storage issues.
2023-04-20 18:22:40 +00:00
Database& database;
Statements statements;
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
RefPtr<Core::Timer> synchronization_timer {};
Browser: Add support for CookieJar to run in a transient, in-memory mode This is to allow running Ladybird without the SQL database for testing. Primarily, this will let us set 'follow-fork-mode' to 'child' within GDB to enter the WebContent process, rather than the SQLServer process. But this is also handy for digging into cookie storage issues.
2023-04-20 18:22:40 +00:00
};
Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
public:
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
static ErrorOr<NonnullOwnPtr<CookieJar>> create(Database&);
static NonnullOwnPtr<CookieJar> create();
~CookieJar();
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 16:56:22 +00:00
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 03:22:27 +00:00
String get_cookie(const URL::URL& url, Web::Cookie::Source source);
void set_cookie(const URL::URL& url, Web::Cookie::ParsedCookie const& parsed_cookie, Web::Cookie::Source source);
Browser+LibWebView+WebContent: Do not domain match on cookie updates Updating cookies through these hooks happens in one of two manners: 1. Through the Browser's storage inspector. 2. Through WebDriver's delete-cookies operation. In (1), we should not restrict ourselves to being able to delete cookies for the current page. For example, it's handy to open the inspector from the welcome page and be able to delete cookies for any domain. In (2), we already are only interacting with cookies that have been matched against the document URL.
2022-11-28 16:24:04 +00:00
void update_cookie(Web::Cookie::Cookie);
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 16:56:22 +00:00
void dump_cookies();
Vector<Web::Cookie::Cookie> get_all_cookies();
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 03:22:27 +00:00
Vector<Web::Cookie::Cookie> get_all_cookies(URL::URL const& url);
Optional<Web::Cookie::Cookie> get_named_cookie(URL::URL const& url, StringView name);
LibWeb+LibWebView: Add an internal API to expire cookies with an offset Cookies have a minimum expiry resolution of 1 second. So to test cookie expiration, the test had to idle for at least a second, which is quite a noticeable delay now that LibWeb tests are parallelized. Instead, we can add an internal API to expire cookies with a time offset to avoid this idle delay.
2024-10-13 12:56:46 +00:00
void expire_cookies_with_time_offset(AK::Duration);
Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
private:
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
explicit CookieJar(Optional<PersistedStorage>);
AK_MAKE_NONCOPYABLE(CookieJar);
AK_MAKE_NONMOVABLE(CookieJar);
Browser: Store cookies in a LibSQL database :^) Currently, cookies are ephemeral and only survive for the lifetime of Browser instance. This will make Browser instead store cookies in a SQL database for persisted access.
2022-10-27 16:56:22 +00:00
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 03:22:27 +00:00
static Optional<String> canonicalize_domain(const URL::URL& url);
LibWebView: Convert trivial ByteString uses to StringView in CookieJar
2024-01-26 15:47:57 +00:00
static bool path_matches(StringView request_path, StringView cookie_path);
Browser: Implement spec-compliant cookie storage https://tools.ietf.org/html/rfc6265#section-5.3 This includes a bit of an update to how cookies are first parsed. The storage spec requires some extra information from the parsing steps than just the actual values that were parsed. For example, it needs to know whether Max-Age or Expires (or both) were specified to give precedence to Max-Age. To accommodate this, the parser now uses an intermediate struct for storing this information. The final Cookie struct is not created until the storage steps. The storage itself is also updated to be keyed by a combo of the cookie name, domain, and path. Retrieving cookies was updated to use the spec's domain-matching algorithm, but otherwise is not written to the spec yet. This also does not handle evicting expired cookies yet.
2021-04-13 03:16:27 +00:00
Browser+WebContent+WebDriver: Move Get All Cookies to WebContent There are a couple changes here from the existing Get All Cookies implementation. 1. Previously, WebDriver actually returned *all* cookies in the cookie jar. The spec dictates that we only return cookies that match the document's URL. Specifically, it calls out that we must run just the first step of RFC 6265 section 5.4 to perform domain matching. This change adds a special mode to our implementation of that section to skip the remaining steps. 2. We now fill in the SameSite cookie attribute when serializing the cookie to JSON (this was a trival FIXME that didn't get picked up when SameSite was implemented).
2022-11-11 14:24:07 +00:00
enum class MatchingCookiesSpecMode {
RFC6265,
WebDriver,
};
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 03:22:27 +00:00
void store_cookie(Web::Cookie::ParsedCookie const& parsed_cookie, const URL::URL& url, String canonicalized_domain, Web::Cookie::Source source);
Vector<Web::Cookie::Cookie> get_matching_cookies(const URL::URL& url, StringView canonicalized_domain, Web::Cookie::Source source, MatchingCookiesSpecMode mode = MatchingCookiesSpecMode::RFC6265);
Browser: Implement spec-compliant cookie storage https://tools.ietf.org/html/rfc6265#section-5.3 This includes a bit of an update to how cookies are first parsed. The storage spec requires some extra information from the parsing steps than just the actual values that were parsed. For example, it needs to know whether Max-Age or Expires (or both) were specified to give precedence to Max-Age. To accommodate this, the parser now uses an intermediate struct for storing this information. The final Cookie struct is not created until the storage steps. The storage itself is also updated to be keyed by a combo of the cookie name, domain, and path. Retrieving cookies was updated to use the spec's domain-matching algorithm, but otherwise is not written to the spec yet. This also does not handle evicting expired cookies yet.
2021-04-13 03:16:27 +00:00
Ladybird+LibWebView: Introduce a cache for cookies backed by SQL storage Now that the chrome process is a singleton on all platforms, we can safely add a cache to the CookieJar to greatly speed up access. The way this works is we read all cookies upfront from the database. As cookies are updated by the web, we store a list of "dirty" cookies that need to be flushed to the database. We do that synchronization every 30 seconds and at shutdown. There's plenty of room for improvement here, some of which is marked with FIXMEs in the CookieJar. Before these changes, in a SQL database populated with 300 cookies, browsing to https://twinings.co.uk/ WebContent spent: 19,806ms waiting for a get-cookie response 505ms waiting for a set-cookie response With these changes, it spends: 24ms waiting for a get-cookie response 15ms waiting for a set-cookie response
2024-05-01 00:05:56 +00:00
Optional<PersistedStorage> m_persisted_storage;
TransientStorage m_transient_storage;
Browser: Initial cookie storage implementation This adds storage for cookies that maye be set via 'document.cookie' in JavaScript or the Set-Cookie HTTP header. For now, it parses only the name-value pair from a set-cookie line, but does not parse optional attributes. Currently, storage is ephemeral and only survives for the lifetime of the Browser instance.
2021-04-11 14:43:54 +00:00
};
}
Browser: Add support for CookieJar to run in a transient, in-memory mode This is to allow running Ladybird without the SQL database for testing. Primarily, this will let us set 'follow-fork-mode' to 'child' within GDB to enter the WebContent process, rather than the SQLServer process. But this is also handy for digging into cookie storage issues.
2023-04-20 18:22:40 +00:00
template<>
AK: Rename GenericTraits to DefaultTraits This feels like a more fitting name for something that provides the default values for Traits.
2023-11-08 19:29:12 +00:00
struct AK::Traits<WebView::CookieStorageKey> : public AK::DefaultTraits<WebView::CookieStorageKey> {
Ladybird+LibWebView: Move CookieJar, Database, and History to LibWebView These classes are used as-is in all chromes. Move them to LibWebView so that non-Serenity chromes don't have to awkwardly reach into its headers and sources.
2023-08-31 11:07:07 +00:00
static unsigned hash(WebView::CookieStorageKey const& key)
Browser: Add support for CookieJar to run in a transient, in-memory mode This is to allow running Ladybird without the SQL database for testing. Primarily, this will let us set 'follow-fork-mode' to 'child' within GDB to enter the WebContent process, rather than the SQLServer process. But this is also handy for digging into cookie storage issues.
2023-04-20 18:22:40 +00:00
{
unsigned hash = 0;
LibWebView: Port the CookieJar to String
2024-01-26 16:39:00 +00:00
hash = pair_int_hash(hash, key.name.hash());
hash = pair_int_hash(hash, key.domain.hash());
hash = pair_int_hash(hash, key.path.hash());
Browser: Add support for CookieJar to run in a transient, in-memory mode This is to allow running Ladybird without the SQL database for testing. Primarily, this will let us set 'follow-fork-mode' to 'child' within GDB to enter the WebContent process, rather than the SQLServer process. But this is also handy for digging into cookie storage issues.
2023-04-20 18:22:40 +00:00
return hash;
}
};
Reference in a new issue Copy permalink