-
Notifications
You must be signed in to change notification settings - Fork 72
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
CORS domain config api and config page #4073
Conversation
Passing run #4279 ↗︎
Details:
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #4073 +/- ##
==========================================
- Coverage 87.51% 87.50% -0.01%
==========================================
Files 326 326
Lines 20283 20324 +41
Branches 2634 2640 +6
==========================================
+ Hits 17750 17785 +35
- Misses 2076 2080 +4
- Partials 457 459 +2
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice job, this seems to work great! I left a few minor comments. I'll leave the backend review to Adam :)
clients/admin-ui/src/features/privacy-requests/privacy-requests.slice.ts
Outdated
Show resolved
Hide resolved
clients/admin-ui/src/features/privacy-requests/privacy-requests.slice.ts
Show resolved
Hide resolved
clients/admin-ui/src/features/privacy-requests/privacy-requests.slice.ts
Outdated
Show resolved
Hide resolved
@adamsachs this should be good to go for another pass 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheAndrewJackson the code re-org looks great! i think having that sort of side-effect function on the ConfigProxy
could be a nice pattern generally.
i just have one concern now on the particular update logic for the cors origins property - i should have realized this before i'd suggested this logic on my previous review 🤦
let me know if it's clear from my comments, i realize things are a bit tricky here and i would be more than happy to talk thru it, since it may be more efficient and i don't wanna hold you up on getting this across the line!
src/fides/api/alembic/migrations/versions/f17f92237383_disable_inactive_notices.py
Outdated
Show resolved
Hide resolved
src/fides/config/config_proxy.py
Outdated
if mw.cls is CORSMiddleware: | ||
current_middleware_domains = ( | ||
mw.options["allow_origins"] | ||
if mw.options["allow_origins"] is not None | ||
else [] | ||
) | ||
current_config_proxy_domains = ( | ||
self.security.cors_origins | ||
if self.security.cors_origins is not None | ||
else [] | ||
) | ||
patch_domains = set( | ||
[*current_middleware_domains, *current_config_proxy_domains] | ||
) | ||
|
||
mw.options["allow_origins"] = [str(domain) for domain in patch_domains] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i know i sorta pointed you toward this implementation on your previous iteration, but i hadn't thought of a consequence of this additive logic that now seems like it could be problematic, unless i'm thinking about this wrong.
with the way this is written, won't we never be able to remove a domain that's been added at some point via config setting? initially a domain will be added to the allow_origins
list/set, and then wouldn't it essentially stay there forever, since it'd continue to be retrieved as a current_middleware_domains
on all subsequent updates (until the service is restarted).
would there be a significant downside to switching the logic here to replace the existing allow_origins
list, so that it's exactly what's been specified in the ConfigProxy
? i'm not sure if there's an initial set of allow_origins
that we need to keep in place from the get-go...if so, i think this problem could be a bit tricky to solve. if not, then i feel like we'd be better off just replacing the cors_origins
with whatever's been specified in the ConfigProxy
.
i guess ultimately i'm wondering on the motivation for making this additive rather than just a replace. it seems to me like the additive logic is a bit at-odds with the way we set our config properties generally, which assumes a replace sort of functionality. i get worried that trying to reconcile those two can be a bit tricky.
sorry i hadn't thought of this on the previous iteration! but just wanna make sure we get this right 👍
if mw.cls is CORSMiddleware: | |
current_middleware_domains = ( | |
mw.options["allow_origins"] | |
if mw.options["allow_origins"] is not None | |
else [] | |
) | |
current_config_proxy_domains = ( | |
self.security.cors_origins | |
if self.security.cors_origins is not None | |
else [] | |
) | |
patch_domains = set( | |
[*current_middleware_domains, *current_config_proxy_domains] | |
) | |
mw.options["allow_origins"] = [str(domain) for domain in patch_domains] | |
if mw.cls is CORSMiddleware: | |
current_config_proxy_domains = ( | |
self.security.cors_origins | |
if self.security.cors_origins is not None | |
else [] | |
) | |
mw.options["allow_origins"] = [str(domain) for domain in current_config_proxy_domains] |
^ may not be exactly how you'd wanna code it, but just to illustrate what i think would lead to a bit more consistent and transparent behavior, if we can get away with it.
# domains and when the `api_set` is reset the middleware | ||
# will still have the `config_set` domains loaded in. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right so this is the behavior that i think would be desirable, but per my above comment i'm worried that this isn't actually exactly what's happening. happy to talk through this more because it gets a bit tricky (and perhaps counterintuitive) with the config proxy, but i actually think that if we're going for this behavior, we can accomplish it with what i suggested above 👍
merge_updates=False, | ||
) | ||
|
||
ConfigProxy(db).load_current_cors_domains_into_middleware(request.app) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BE is looking nice after all the iterations 😄
i have a sneaking suspicion we'll be coming back to the /config
API again sometime soon since i feel like edge cases abound (not the concern of this PR), but i feel comfortable this is serving our current purposes well 👍
thanks for all the back and forth on this, i think we landed in a nice spot and are pushing some more generic functionality ⏩
Closes fidesplus#1065
Description Of Changes
Add CORS configuration to the admin ui and config proxy api.
Screen.Recording.2023-09-14.at.09.38.37.mov
Code Changes
cors_origin
security fieldcors_origin
s within the CORS middleware at runtimeSteps to Confirm
nox -s dev
const plus = true;
so the admin ui thinks plus is running/management/cors-configuration
Pre-Merge Checklist
CHANGELOG.md