[Feature]: Document or fix obscure base64 alphabet for cookie secret option

Motivation

There are two base64 alphabets defined in RFC4648 and supported in go https://pkg.go.dev/encoding/base64

• the standard one ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ which is used by most tools (e.g. openssl rand -base64 32 or base64)
• URL/filename safe which substitutes +/ for -_. This seems to be far less known and less widely used (I didn't know about it until today)

cookie_secret is documented as "the seed string for secure cookies (optionally base64 encoded)". In practice this is handled by SecretBytes which attempts to decode the string as base64, if the resulting string is an invalid length or fails to decode then it uses the raw bytes. It uses the URL safe base64 alphabet for decoding.

Throughout the docs it does say to use python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())' to generate a secret, which does use the URL safe alphabet, however this decision is never explicitly called out. Based just on the cookie_secret documentation there is no reason to believe that you can't use head -c 32 /dev/random | base64 or openssl rand -base64 32.

This should be addressed either by supporting normal base64 alphabet in addition to the URL safe base64 alphabet, or by updating documentation to make it clear that the less common alphabet is required.

Possible solution

There are a couple of ways to approach this:

• If there is no hard requriement that the cookie secret be encoded with URL safe base64 then I'd suggest supporting both. Modify SecretBytes to attempt decoding using first RawURLEncoding then RawStdEncoding; use the first one that works. SecretBytes is used by other callers though, I'm not sure what the implications are here. Possibly it may be worth splitting the function based on caller.
• If there is some requirement that the cookie secret option must be URL safe and can't be encoded with normal base64 alphabet, then update docs to reflect this.

Provider

None