You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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:
I suppose this should be considered a major update since people's current environment variables may rely on the old defaults to achieve what they want.
apiIssue related to the REST APIfixfront-endIssue related to the React Front End Dashboard
2 participants
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: