Expose waffle flags through an API route#1072
Conversation
| Callers authenticate with `Authorization: Bearer <keycloak-access-token>` | ||
| and we resolve that to the matching local user via OIDCAuthentication. | ||
| """ | ||
| flags = get_waffle_flag_model().get_all() |
There was a problem hiding this comment.
I think it might be easier to pull in waffle.views.waffle_json, do the auth checks in this function and pass the request in to waffle_json and return that. We basically just want to wrap it with our token auth.
There was a problem hiding this comment.
Sure, changed to just forwarding what comes from waffle_json, thanks!
This will expose not only the flags but also the switches and samples but I think that's fine?
MelissaAutumn
left a comment
There was a problem hiding this comment.
We're just testing / allowing session auth here. I think we might need to create a django rest framework auth class (subclassing is fine) to allow ingesting access token via jwt bearer token (so headers['authorization'] = 'bearer '.)
|
Oh I thought OIDCAuth was ours, but it's drj. Looks like it does what we need to do. Could you adjust the tests to explicitly use headers['authorization'] = 'bearer xyz'. You might need to mock |
|
@MelissaAutumn awesome thanks for the review and suggestions! Updated the code in the latest commits. |
MelissaAutumn
left a comment
There was a problem hiding this comment.
Thanks! One suggestion for an extra test. Good to go otherwise.
| self.assertEqual(200, response.status_code, response.content) | ||
| self.assertFalse(response.json()['flags']['flag-on-for-specific-user']['is_active']) | ||
|
|
||
| def test_requires_authentication(self): |
There was a problem hiding this comment.
One last suggestion, a test for a bogus bearer token / bogus auth value.
* Add new GET auth/waffle-flags endpoint * Add tests for auth/waffle-flags endpoint * Just forward waffle_json instead of surfacing flags only * Update tests to explicitly pass bearer token headers * Add extra test for fake bearer token
What changed?
Added a GET
api/v1/auth/waffle-flags/route that gets the feature flags available for the logged in user.Why?
A centralized place to control feature flags across services would be great and since we already have django-waffle set up here we can simply make a request from other services instead of having service-specific env var-based flags.
Limitations and Notes
Since this is machine-to-machine, we lose the ability to rely on Waffle cookies for percent-rollout sticky-ness across calls unless another rule also qualifies the user.
Applicable Issues
Closes #1064