fix!: (WIP) Disable Secure cookies by default, enable when using HTTPS #5011
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change possibly fixes #4940, though is a breaking change.
Secure cookies are now opt-in instead of opt-out. By default, secure cookies are now automatically enabled if the request is secure. Users can still force secure cookies if needed.
Having secure cookies enabled by default means that Flagsmith must be used on HTTPS or localhost exclusively. Deploying our provided Docker Compose definition or Helm chart and trying to access it over anything except HTTPS or localhost will fail, unless secure cookies are disabled. Specifically this will fail on any origin that is not potentially trustworthy, which is essentially everything except HTTPS,
127.0.0.1
,::1
, and localhost.This is particularly annoying when testing Kubernetes or Docker deployments, where it's often easier to access services using service URLs and not port forwarding to localhost. The behaviour when secure cookies fail is also confusing, where users can log in but are immediately logged out with no visible errors when reloading the page.
I consider these new defaults to be more secure for most users - they allow testing and experimenting over HTTP when it is not a concern, and they provide secure behaviour when using HTTPS in production. With the current situation, users might forget to opt back into secure cookies after needing to disable them for testing over HTTP, and carry a less secure configuration into a production deployment.
There are legitimate use cases for using Flagsmith in production over HTTP such as having a VPN deal with TLS instead of the application, or local networks.
The Helm chart could also be made to force HTTPS depending on values or ingress configuration.
Testing
Running the
ghcr.io/flagsmith/flagsmith-private-cloud:pr-5011
image on Kubernetes, we can successfully log in and access the cluster over HTTP using the default settings:Connecting with the same settings over HTTPS sets a secure cookie - the load balancer here is OrbStack using Docker Compose: