seqcli apikey create with --connect-username fails over HTTP if the server's canonical URI is HTTPS #2503
Description
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.