When SEQ_API_CANONICALURI is an HTTPS URL, Seq marks the username/password login authentication cookie with secure. This is intentional, we don't want to leave the secure flag off just because Seq is behind a load balancer and we didn't get the expected host or forwarding header.
In this situation, browsing Seq over a plain HTTP URL (e.g. http://localhost) still works because browsers appear to happily ignore this flag when the origin is an HTTP URL.
The .NET CookieContainer used by Seq.Api (and thus seqcli) is stricter, and won't send the auth cookie back if the next request is via plain HTTP, even if the cookie was itself received via plain HTTP.
Unfortunately, this interferes with initial provisioning scenarios where seqcli apikey create --connect-username= is used to create an API via localhost on a new/blank Seq server.
Since the cookie container used by seqcli is ephemeral, there's no browser involved, and the user has explicitly requested that it make a plain HTTP connection, the most appropriate fix is probably to loosen up the API client's cookie handling behavior only when the hostname is localhost or the loopback IP.
datalust/seq-tickets#2502 (reply in thread)
When
SEQ_API_CANONICALURIis an HTTPS URL, Seq marks the username/password login authentication cookie withsecure. This is intentional, we don't want to leave thesecureflag off just because Seq is behind a load balancer and we didn't get the expected host or forwarding header.In this situation, browsing Seq over a plain HTTP URL (e.g.
http://localhost) still works because browsers appear to happily ignore this flag when the origin is an HTTP URL.The .NET
CookieContainerused bySeq.Api(and thusseqcli) is stricter, and won't send the auth cookie back if the next request is via plain HTTP, even if the cookie was itself received via plain HTTP.Unfortunately, this interferes with initial provisioning scenarios where
seqcli apikey create --connect-username=is used to create an API via localhost on a new/blank Seq server.Since the cookie container used by
seqcliis ephemeral, there's no browser involved, and the user has explicitly requested that it make a plain HTTP connection, the most appropriate fix is probably to loosen up the API client's cookie handling behavior only when the hostname is localhost or the loopback IP.datalust/seq-tickets#2502 (reply in thread)