An HTTP 400 "Bad request" page following successful password reset with a toast (not visible in the screenshot because it was auto-dismissed after timeout) containing the success message.
This just happened. I'm not sure how reproducible it is, but here are the steps (I just don't want to go through them again to confirm):
1. Visit kosmos.org
2. Click "Log in" link
3. Submit username and password guess
4. Repeat step 3 with another password
5. Click the forgot password link
6. Submit email address
7. Open the "Reset password instructions" email from accounts@kosmos.org
8. Click the "Change my password" link
9. Enter new password 2x and submit the form
Expected results:
Successful password reset with success feedback
Actual results:
An HTTP 400 "Bad request" page following successful password reset with a toast (not visible in the screenshot because it was auto-dismissed after timeout) containing the success message.
This is an edge case, but a valid issue, and it touches on a related issue, too.
The actual 400 came from an invalid RS auth URL (invalid params) that was stored as an after-sign-in URL upon hitting the sign-in requirement for that URL.
In general, after-sign-in URLs currently aren't cleared properly, so they can persist across sign-ins, causing funky redirect behaviors here and there.
Thanks for the report! PR incoming, which will contain multiple fixes, incl. validating the RS OAuth params beforehand, so the 400 is served immediately and in context.
This is an edge case, but a valid issue, and it touches on a related issue, too.
The actual 400 came from an invalid RS auth URL (invalid params) that was stored as an after-sign-in URL upon hitting the sign-in requirement for that URL.
In general, after-sign-in URLs currently aren't cleared properly, so they can persist across sign-ins, causing funky redirect behaviors here and there.
Thanks for the report! PR incoming, which will contain multiple fixes, incl. validating the RS OAuth params beforehand, so the 400 is served immediately and in context.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
This just happened. I'm not sure how reproducible it is, but here are the steps (I just don't want to go through them again to confirm):
Expected results:
Successful password reset with success feedback
Actual results:
An HTTP 400 "Bad request" page following successful password reset with a toast (not visible in the screenshot because it was auto-dismissed after timeout) containing the success message.
This is an edge case, but a valid issue, and it touches on a related issue, too.
The actual 400 came from an invalid RS auth URL (invalid params) that was stored as an after-sign-in URL upon hitting the sign-in requirement for that URL.
In general, after-sign-in URLs currently aren't cleared properly, so they can persist across sign-ins, causing funky redirect behaviors here and there.
Thanks for the report! PR incoming, which will contain multiple fixes, incl. validating the RS OAuth params beforehand, so the 400 is served immediately and in context.