-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add org propagation [ZEN-340] #161
Conversation
This PR modifies files linked to issues tracked in Stepsize. You might want to review their status, priority, and scope. duplicate arguments for analysis context
Interfaces can easily go out of sync
|
d1d8af3
to
d38d774
Compare
d38d774
to
08a6364
Compare
This PR modifies files linked to issues tracked in Stepsize. You might want to review their status, priority, and scope. duplicate arguments for analysis context
Interfaces can easily go out of sync
|
🎉 This PR is included in version 4.13.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Jira ticket: ZEN-340
Related PRs
deeproxy#211
registry#29177
Context
Since the introduction of the new services, we started fetching the org's FFs in
registry
whendeeproxy
performs a token validation to its endpoint. Previously, this operation did not require the current org, so the default one was used byregistry
.We currently want the FFs of the org being used, so we need to propagate the org provided in
CLI
by either the flag or the config.Relevant code-client requests to propagate the org
From my investigation, it seems that the only
code-client
requests performed byCLI
that triggers a token verification are:The last one,
getAnalysis()
, already had the proper relay of the org, so the only change necessary was adding the header fordeeproxy
.The flows (and changes) for the requests are simplified in the following diagrams:
TODO