-
-
Notifications
You must be signed in to change notification settings - Fork 964
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
fix: Run post recovery hook before storing the session and issuing a cookie #3393
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3393 +/- ##
=======================================
Coverage 78.07% 78.07%
=======================================
Files 327 327
Lines 21377 21377
=======================================
Hits 16690 16690
Misses 3455 3455
Partials 1232 1232 |
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.
It would be great to add a test that verifies this behavior. As all other tests are passing, it seems that at least it is not breaking anything.
@zepatrik Definitely. I wanted to make sure the existing tests were passing and haven't had the chance yet to add the new tests. I'll remove the |
}) | ||
|
||
t.Run("description=should not be able to recover if post recovery hook fails", func(t *testing.T) { | ||
conf.MustSet(ctx, config.HookStrategyKey(config.ViperKeySelfServiceRecoveryAfter, config.HookGlobal), []config.SelfServiceHook{{Name: "err", Config: []byte(`{"ExecutePostRecoveryHook": "err"}`)}}) |
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 couldn't figure out a good way to mock a 4xx response to the webhook request so that I could test the message in the response would show up in the new flow.
Technically this change could be considered breaking. But I think it is just restoring the intended behaviour. |
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.
Looks very good, I think this error case should be enough.
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.
LGTM!
If the response to a flow-interrupting, after recovery webhook is
4xx
or5xx
, the recovery flow should fail and no session should be issued.Related issue(s)
Fixes #3193
Checklist
introduces a new feature.
contributing code guidelines.
vulnerability. If this pull request addresses a security vulnerability, I
confirm that I got the approval (please contact
[email protected]) from the maintainers to push
the changes.
works.