-
Notifications
You must be signed in to change notification settings - Fork 6
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
[#2932] Skip KVK branch selection if vestigingsnummer already selected #1526
Conversation
c9f6c00
to
2403f68
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #1526 +/- ##
========================================
Coverage 94.25% 94.26%
========================================
Files 1068 1068
Lines 40466 40508 +42
========================================
+ Hits 38141 38183 +42
Misses 2325 2325 ☔ View full report in Codecov by Sentry. |
2403f68
to
160e7c6
Compare
Braindump: @pi-sigma this is technically orthogonal to the issue here (skipping the branch if already selected during the eHerkenning flow), but it's also important that users can see only vestigingen they're authorized to see according to the eHerkenning scope. I am not sure if that flows from this claim (Selected branch) versus some other claim that may or may not exist (all authorized branches). |
160e7c6
to
90916fa
Compare
@swrichards Good point. Is this already covered by our use of |
e9d46da
to
32aff77
Compare
2ed8c7d
to
2262b02
Compare
46cac08
to
bad1692
Compare
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.
Just one question about the claims: I'll leave it up to you whether we need to fix this now or whether it needs fixing at all.
bad1692
to
359d14c
Compare
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.
Very small nitpicks, otherwise GTG!
msg = f"eHerkenning user (KVK/RSIN = {kvk_or_rsin}) retrieved with vestigingsnummer from IdP" | ||
if user_created: | ||
msg = f"eHerkenning user (KVK/RSIN = {kvk_or_rsin}) created with vestigingsnummer from IdP" |
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.
Should this be in this method? It's strictly speaking about the vestigingsnummer. If we're logging anything here, I'd say we log that we did (or did not) find a vestigingsnummer, and leave the "we created or updated a user" in the function where that happens.
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.
You're right, that "retrieve/create" dichotomy indicates that the message is rather specific to the calling functions. I'll change and simplify accordingly.
|
||
if not (branch_number_claims := eherkenning_config.branch_number_claim): | ||
return | ||
if not (vestigingsnummer := claims.get(branch_number_claims[0])): |
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.
Just out of interest: did we figure out if there are ever multiple claims? No need to hold up the PR for that, just curious.
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.
No. I'm not sure what the use case would be, but the library definitely makes room for this.
if not (identifier_type_claims := eherkenning_config.identifier_type_claim): | ||
return | ||
|
||
kvk_or_rsin = identifier_type_claims[0] |
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.
Are we fetching this only for the logging? In that case I'd also say we log this earlier in the chain, there's a lot of escape hatches in this function making it slightly harder to follow, if we can simplify it that'd be better.
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 think the escape hatch for the identifier_type_claim
is unnecessary. If you're logging in with eHerkenning, the KVK or RSIN needs to be in the claims
if not (branch_number_claims := eherkenning_config.branch_number_claim): | ||
return |
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.
My sense is this is an optional in a "you might not have eHerkenning set up" kind of way, but if we make it to this function, eHerkenning is evidently configured, and then I feel a Sentry ping would be in order to at least alert us to the incomplete configuration.
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.
In fact, the _check_candidate_backend
already takes care of this, and since the config class provides a default for the claim field, this is guaranteed to exist. Will simplify
- When logging in with eHerkenning via OIDC, get the vestigingsnummer from the OIDC claim (if present) and store in session
359d14c
to
fcb4c6b
Compare
The KVK branch selection page should be skipped for users who have already selected a branch on a different platform
Taiga: https://taiga.maykinmedia.nl/project/open-inwoner/task/2932