An open-source, on-prem feature flag solution

Describe the Bug

We are running flipt in k8s in multiples environment:

• locally using rancher desktop k8s.
• in gcp

we are in 1.8.3 and everything is working well, but when we try to update to 1.9.0 or 1.10.0 (even on a new db), we got error.

getting db driver for: postgres: dial tcp: lookup postgres.database.svc.cluster.local: device or resource busy

Version Info

1.8.2 -> working 1.8.3 -> working 1.9.0 -> error 1.10.0 -> error

our posgres sql is postgres:12

To Reproduce

we just start the docker image with the env variable FLIPT_DB_URL to postgres://[email protected]:5432/flipt?sslmode=disable

I went to the list of change, but I could not see any change related to postgres. Did we miss something or we need to change something ?

log

Version: 1.9.0
Commit: 9938aba8e9c67aa4789bf0eec384d4113dd567d1
Build Date: 2022-08-26T07:05:51Z
Go Version: go1.17.11

A newer version of Flipt exists at https://github.com/flipt-io/flipt/releases/tag/v1.10.0, 
please consider updating to the latest version.
time="2022-08-26T07:05:53Z" level=info msg="shutting down..."
time="2022-08-26T07:05:53Z" level=error msg="getting db driver for: postgres: dial tcp: lookup postgres.database.svc.cluster.local: device or resource busy"

Is your feature request related to a problem? Please describe. Hi, we actively used redis as storage, and I want to add this feature. I've found this issue https://github.com/markphelps/flipt/issues/174 but it was closes because author inactivity, so can I add?

Describe the solution you'd like I would like to add Redis as storage

Hey @markphelps—great work.

I'm thinking about using flipt for a product I'm developing, however, I am not sure if I'm doing something wrong.

I've created one flag called "test" with a segment that matches on all contexts and a targeting rule on set to 50% and off also set to 50%. I can't seem to get a match: true or match: false back from the server.

Extending variant to support attachment

• Extend flipt.proto to support attachment in variant
• Extend DB with the new column
• Extend UI to support the new field

closes https://github.com/markphelps/flipt/issues/188

flipt:latest kubernets cluster

If I start flipt in our cluster without any modification, the flipt service starts without any problem. After looking into /var/opt/flipt there is a file flipt.db. Doing the same with a mounted pvc/volume, flipt is starting with an error.

You are currently running the latest version of Flipt [1.9.0]!
time="2022-07-21T23:24:57Z" level=info msg="shutting down..."
time="2022-07-21T23:24:58Z" level=error msg="getting db driver for: sqlite3: unable to open database file: no such file or directory"

Using an init container I see hat the flipt.db is not existing while startup the container. It looks like the flipt.db file is created on startup.

So I assume flipt is creating the flipt.db on startup. BUT it will not create this file inside the mounted volume.

Maybe flipt expect a mounted volume as an external database and will not create flipt.db?

Because the file flipt.db is not existing on pod startup, I also cannot use an init container as workaround to copy the file to the mounted volume.

Describe the bug When i send this request to flipt /api/v1/evaluate:

{"flag_key":"profile","entity_id":"ccf4c0a9-fc44-4478-a790-a01762efff01","context":{"cohort":null}}

I'm getting the following response body as status 400:

{"code":3,"message":"proto: (line 1:102): invalid value for string type: null","details":[]}

This is a bug because this does break the default behavior and was not documented in changelog.

Version Info version 1.5.0 as docker image.

To Reproduce The steps are well written in the description

Expected behavior The response should be status 200, with body similar to this:

{
    "requestId": "728457c6-7dcd-46ff-9779-73b8988422a0",
    "entity_id":"ccf4c0a9-fc44-4478-a790-a01762efff01"
    "requestContext": {
        "cohort":null
    },
    "match": false,
    "flagKey": "profile",
    "segmentKey": "",
    "timestamp": "2022-01-25T17:13:51.337894649Z",
    "value": "",
    "requestDurationMillis": 3.700846
}

• Using postgres

Is your feature request related to a problem? Please describe. I need to toggle a feature in response to a certain parameter, e.g. I have 5 admin emails and if the API call sends one of them in the validate call, the feature should be toggled on by responding with true. Currently I create a segment for each with the constraint email to be equal and the flag returns true for these segments. But setting several emails to the segment as constraints, since it checks if the given email is equal to all of them does not work. Only if just one email is provided.

Describe the solution you'd like Maybe set the option of the segment from always match all to be switchable to match one of. That way, I would only need to create one segment, give them all the emails as constraints and if the email matches one of the constraints, its in that segment and the feature flag would return true.

Additional context I really enjoy your work and it is a great help. Thank you.

Maybe not a top priority right now...but do you think there's a way to batch-evaluate a set of flags?

I plan to use the REST API instead of grpc—so like, it'd be nice if I could send a single request with a set of flags to be evaluated instead of 1 request per flag. Just to avoid all the roundtrips.

Thoughts?

Overview

The format of cors.allowed_origins config was changed by https://github.com/flipt-io/flipt/pull/1079 refactoring. So I change the test case to explain the format explicitly.

Explanation

Before the above change at v1.13.0, the format with white space worked fine since the parameter was parsed by viper.GetStringSlice here. But after the above change, it is parsed by mapstructure.StringToSliceHookFunc(",") here so the expected format was changed. I'm not sure we should fix to parse for the previous format, but changing test case to show the correct format won't be harmful.

As discussed in #385 this is the step 2: align the codebase to spin up the service and expect it on 127.0.0.1 instead of 0.0.0.0. To be applied whenever @markphelps release a new version, to avoid any back-compatibility issues you may have in mind.

A new demo.gif is required.

Goal

Upgrade to latest versions of JS dev dependencies

What I Did

~/workspace/flipt/ui yarn-dev-deps
❯ yarn version
yarn version v1.17.0

yarn upgrade-interactive --latest

To upgrade all dependencies

What Happens

When I run yarn dev, it opens the browser but then I get:

Uncaught TypeError: Cannot assign to read only property 'exports' of object '#<Object>'

In the console

What Should Happen

No JS errors in the console when running yarn dev

use fresh minted GITHUB_TOKEN when calling setup-task in workflows to avoid GitHub rate limits causing jobs to fail

ex: https://github.com/flipt-io/flipt/actions/runs/3832718965/jobs/6523354201#step:6:5

https://github.com/arduino/setup-task#repo-token

• Performs some refactoring i've wanted to do for awhile, moving the release / version check mechanism out of main (mostly) and adding some tests around it
• Also checks for rc in version to determine if its a proper release or not

Fixes FLI-116

This adds support for a configurable CSRF key to be added and protection to be enforced.

When configured (non-empty authentication.crsf.key) a CSRF credential will be configured and stored in a cookie when accessing any of the following API prefixes:

• /api/v1
• /auth/v1
• /meta

Attempts to use non-safe (all bar GET or HEAD) HTTP methods will require an acquired CSRF token be presented. The token is verifiable via the CSRF credentials stored in the cookie (signature verification is used).

The token can be acquired via a response header obtained on any route beneath /meta. The UI performs a /meta/info request in each load. This is where the current UI is obtaining it and storing it in its Vuex store.

The UI has been updated to obtain the token and present it on all subsequent API requests. The new UI will need a similar adjustment to be made to support CSRF.

This method of prevention ensures that a malicious request cannot be crafted from another domain / origin and directed over to Flipt to perform a malicious operation (e.g. delete or update a flag or authentication).

There is one caveat, and that is the enforcement is only performed when the request contains an Origin header. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

This is taken from the MDN link above:

Broadly speaking, user agents add the Origin request header to:

• cross origin requests.
• same-origin requests except for GET or HEAD requests (i.e. they are added to same-origin POST, OPTIONS, PUT, PATCH, and DELETE requests).

This ensures we enforce the policy for browser user-agents. However, not for other clients (e.g. our SDKs). Thereby avoiding having to teach clients to perform the same CSRF prevention, which should be an unnecessary security step for our SDKs. As, the attack is performed by manipulating a user's browser and cookie-based authentication.

Problem

Great thing to use Zap as logger. Unfortunately the logger keys are hardcoded in main.go. At least GCP looging cannot understand the logger keys. Alle entries at now are logged at INFO severity.

Ideal Solution

So it would be great to set the complete Zap logger config like this:

level: debug
development: false  # enables stacktrace!
encoding: json  # or 'console'
outputPaths:
  - stdout
errorOutputPaths:
  - stderr
encoderConfig:
  timeKey: time
  levelKey: level
  messageKey: msg
  levelEncoder: capital  # or 'lower'
  timeEncoder: iso8601  # o 'rfc3339'
  callerEncoder: full

Which then looks like this:

Bumps eslint from 8.28.0 to 8.31.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.