[linkdata]

Summary

• Use __Host-<CookieName> for sessions when JaWS recognizes HTTPS. These cookies carry Secure, Path=/, and no Domain.
• Keep the existing unprefixed cookie name for plain HTTP. HTTP and HTTPS sessions are separate; lookup and replacement cannot cross that boundary, even if a client copies a valid ID under the other cookie name.
• Treat explicitly __Host-, __Secure-, and __Http- prefixed names as HTTPS-only, case-insensitively. Emit __Host- in canonical case for older browsers and document proxy scheme configuration and migration.
• Update the tracked JaWS AI guidance: jawsauth keeps sessions on login and logout by default; applications need no cookie monitoring; login rotation is an explicit setting for a concrete fixation path.

Browsers that enforce the __Host- prefix reject attempts by sibling domains or plaintext HTTP responses to set the HTTPS session cookie. Rotation is useful only if an attacker can make a victim use a known pre-login cookie, share the effective client IP JaWS sees, and cannot obtain the later cookie. linkdata/jawsauth#23 makes rotation opt-in.

Compatibility

• Merge jawsauth add Jaws.ServeHTTP() #23 first: the JaWS AI guidance in this PR describes its new default and RotateSessionOnLogin setting.
• Plain HTTP sessions continue working with CookieName; they do not share sessions with HTTPS.
• Existing HTTPS cookies with the old unprefixed name are ignored. Users with those cookies sign in again.
• Behind a trusted TLS-terminating proxy, enable TrustForwardedHeaders and have the proxy replace client-supplied forwarding headers so JaWS sees the actual scheme and client IP.

Verification

• go generate ./...
• go vet ./...
• go build ./...
• go test -race ./... (full module)
• go test ./...
• staticcheck ./..., golangci-lint run, gosec ./...
• gofmt -l . and gofumpt -l on changed Go files
• git diff --check on the AI guidance update