Prevent admin from invalidating their own password #708
Conversation
I don't think an admin would ever want to reset and invalidate their own password rather than changing their password. If they did invalidate their password, their sessions would be deleted, including their current session. That would lead to the issue described in #705.
| <li :class="{ disabled }"> | ||
| <a class="reset-password" href="#" | ||
| v-tooltip.aria-describedby="disabled ? $t('cannotResetPassword') : null" | ||
| @click.prevent="$emit('reset-password', user)"> |
There was a problem hiding this comment.
This is very similar to how we disable the retire button directly below.
| it('is disabled for the current user', async () => { | ||
| const component = await load('/users', { root: false }); | ||
| const a = component.get('.user-row .reset-password'); | ||
| a.element.parentNode.classList.contains('disabled').should.be.true(); | ||
| a.should.have.ariaDescription(/^You may not reset your own password/); | ||
| await a.should.have.tooltip(); | ||
| }); |
There was a problem hiding this comment.
This is very similar to the test in test/components/user/retire.spec.js that the retire button is disabled for the current user.
|
@alxndrsn, I've tagged you for review here with the thought that the changes here are very similar to how things are done elsewhere in the codebase. I figure you could probably verify that even without having written a lot of component code in Frontend, but let me know if it'd be better for me to tag someone else. |
I figure that if an admin wants to use the API to invalidate their own password, YOLO. Their session token won't work for future requests, but that's an outcome they should be prepared for after invalidating their password. The API will invalidate a password during a password reset only if |
|
@matthew-white |
|
Good question. It should be possible to reset anyone's password using that process. The difference between requesting a password reset from the page in the screenshot above and requesting it from the Users page is that when a reset is initiated from the Users page, the user's password is immediately invalidated. In contrast, the page above is only available to someone who isn't logged in already. If you aren't logged in, you can request a password reset for anyone, but that won't invalidate anyone's existing password. (Otherwise you could invalidate someone's password just by knowing their email address.) An admin shouldn't be able to request a reset of their own password from the Users page because that would immediately invalidate their password, which would cause other issues. However, if the admin isn't logged in, they should be able to request a password reset from the page above; it just won't invalidate their password. Does that make sense? |
|
Yes, It's pretty clear now :) |
|
Tested with success! |
|
Tested with success! |
See the commit message for notes.
Note for the QA team: You can verify this by looking for "Reset password" in the actions dropdown on the Users page. It should be disabled for the current user.