Documentation Updates

Checked 4 published document(s). No updates required.

^{How did I do? Any feedback?}  

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.29%. Comparing base (9497379) to head (d65c8e5).
⚠️ Report is 1 commits behind head on v2.

@@            Coverage Diff             @@
##               v2    #4934      +/-   ##
==========================================
+ Coverage   59.07%   60.29%   +1.21%     
==========================================
  Files         135      136       +1     
  Lines       16908    13372    -3536     
==========================================
- Hits         9988     8062    -1926     
+ Misses       6239     4629    -1610     
  Partials      681      681              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@erka instead of making it a configuration thing, I thought we would just accept a parameter in the ListFlagsRequest to include metadata, that way it can just be done at request time, no configuration needed

@erka instead of making it a configuration thing, I thought we would just accept a parameter in the ListFlagsRequest to include metadata, that way it can just be done at request time, no configuration needed

How will this prevent sensitive metadata from being exposed to someone with a hijacked request? @markphelps

@erka instead of making it a configuration thing, I thought we would just accept a parameter in the ListFlagsRequest to include metadata, that way it can just be done at request time, no configuration needed

How will this prevent sensitive metadata from being exposed to someone with a hijacked request? @markphelps

Im not sure how much we should be worried about that tbh. It just seems weird to me that we would make this a configuration thing as we dont have a precedence for it and it feels more like it should be a per request option

In issue #2682, it’s mentioned that:

Often, feature flags are tied to pull requests, GitHub issues, or other internal documents.

There’s a management v2 API for viewing and updating flag metadata, which already has authentication and authorization in place.

Currently, I see that the List Flags v1 API is public and part of the evaluation API. I’m concerned that this could expose private data in existing deployments, which for some users might even result in a security incident. There should be an explicit configuration to prevent this. I still remember the v1 /meta/config endpoint and how many times it led to secret leaks — I really don’t want to see the same thing happen here.

I see the Evaluation API and this V1 List Flags API as data API - read-only and safe to expose publicly. And V2 API as management API - read-write operations with authentication/authorization.

In issue #2682, it’s mentioned that:

Often, feature flags are tied to pull requests, GitHub issues, or other internal documents.

There’s a management v2 API for viewing and updating flag metadata, which already has authentication and authorization in place.

Currently, I see that the List Flags v1 API is public and part of the evaluation API. I’m concerned that this could expose private data in existing deployments, which for some users might even result in a security incident. There should be an explicit configuration to prevent this. I still remember the v1 /meta/config endpoint and how many times it led to secret leaks — I really don’t want to see the same thing happen here.

these are good points.

wdyt about us creating a evaluation configuration section and putting this include_flag_metadata there. that way its clear that it will be returned from the evaluation APIs like 'list flags' and we could also return it in the actual evaluation calls like was mentioned in #2682

Yes, that may be a good place for such configuration.