Cache conflict in Redis for Get Flags and Get Identities endpoints in the Flagsmith API

[oluizcarvalho]

How are you running Flagsmith

• [ ] Self Hosted with Docker
• [x] Self Hosted with Kubernetes
• [ ] SaaS at flagsmith.com
• [ ] Some other way (add details in description below)

Describe the bug

A cache issue occurs in the Get Flags and Get Identities endpoints of the Flagsmith API when using Redis for caching, configured as described in the official documentation.

The keys saved in Redis do not include the api_key as part of the key attributes, causing cache overwrites and response conflicts between different API calls.

Upon analyzing the code, it seems that the cache controller is overwriting the cache keys in Redis. The current structure of the Redis keys is as follows:

:1:views.decorators.cache.cache_page..GET.<hash>.d41d8cd98f00b204e9800998ecf8427e.<locale>.<timezone>

This results in inconsistent responses.

Example of the Issue API_KEY_1 makes a request to the Get Flags endpoint and saves a response in Redis. API_KEY_2 (different project) makes a request to the same endpoint but receives the response saved by API_KEY_1.

Steps To Reproduce

1. Configure the Flagsmith API with Redis caching for the Get Flags and Get Identities endpoints using the following settings:

GET_FLAGS_ENDPOINT_CACHE_SECONDS=300
GET_FLAGS_ENDPOINT_CACHE_BACKEND=django.core.cache.backends.redis.RedisCache
GET_FLAGS_ENDPOINT_CACHE_LOCATION=redis://username:[email protected]:6379

GET_IDENTITIES_ENDPOINT_CACHE_SECONDS=300
GET_IDENTITIES_ENDPOINT_CACHE_BACKEND=django.core.cache.backends.redis.RedisCache
GET_IDENTITIES_ENDPOINT_CACHE_LOCATION=redis://username:[email protected]:6379

2. Make a request to the Get Flags endpoint using API_KEY_1.
3. Make another request to the same endpoint using API_KEY_2 (different project).
4. Observe the responses returned.

Expected behavior

1. Redis cache keys should include the api_key as part of their structure to ensure data is unique to each API request.
2. Responses for API_KEY_1 and API_KEY_2 should be independent and consistent with the expected data.

Screenshots

API_KEY_1:

API_KEY_2 (different project) with cache:

API_KEY_2 no cache:

[oluizcarvalho]

@matthewelwell Did you manage to take a look?

[matthewelwell]

@oluizcarvalho thanks for raising this, and for the detailed issue description, and apologies for the delay in getting back to you.

We will try to get to this as soon as we can, unless you want to submit a PR for it yourself?

[oluizcarvalho]

You can continue with the corrections, if you need any support just tell me, thank you

[brunosmm]

@matthewelwell any updates on this? Is there another cache layer which is working?

[safonovklim]

Confirmed same impact on environment-level here https://github.com/Flagsmith/flagsmith/issues/5726

[matthewelwell]

As discussed in our sprint planning, it looks like we just need to add the vary_on_header decorator to the view methods.

[oluizcarvalho]

Thanks for the support guys