Configure Session Cookies
Security Requirements and Controls
Change sessions
permission
Learn how to configure session cookies in LogScale across domains and subdomains, including default behaviors, security requirements, and manual configuration options, with specific guidance on when to use bearer token authorization instead of cookies and how to configure essential parameters like COOKIE_DOMAIN, COOKIE_PATH, COOKIE_SECURE, and COOKIE_SAMESITE.
LogScale defaults to using cookies as a secure mechanism to establish a session between the LogScale web frontend and backend API. The only information that's stored in a LogScale session cookie is a session identifier.
Cookies are automatically configured based on your
PUBLIC_URL
. They can also be configured manually via the
LogScale configuration file or completely disabled and instead relying on
a less secure bearer token.
Using cookies puts a constraint on how the web frontend and backend API is served:
The frontend needs to be on the same domain or subdomain as the backend API.
If the web frontend and backend are both served from
https://cloud.humio.com
you do not need to configure anything manually.If the frontend is served from e.g.
https://cloud.humio.com
and the backend is served from a subdomain such ashttps://api.cloud.humio.com
you need to setCOOKIE_DOMAIN
tocloud.humio.com
. That's because if a domain is specified, then subdomains are always included. Therefore, specifying the domain is less restrictive than omitting it.If you have a need of serving the backend API and frontend from two different domains with no subdomain relation, you cannot use secure cookies. Instead you need to use a less secure bearer token. This is done by enabling bearer token authorization via the configuration option:
ENABLE_BEARER_TOKEN_AUTHORIZATION=true
Manual Configuration
These are the configuration parameters that control the cookie behaviour when installed on your infrastructure:
Please see Mozilla Developer for a detailed discussion.