Add permission check for admins updating user passwords #3394
Conversation
| @@ -58,21 +58,4 @@ | |||
| <% end %> | |||
|
|
|||
| </div> | |||
|
|
|||
| <div data-hook="admin_user_form_password_fields" class="col-6"> | |||
There was a problem hiding this comment.
I'm not sure if we should delete this div with the form fields or not. There maybe stores using this data-hook so I'm thinking that perhaps we should leave it in for backwards compatibility. Although I'm also annoyed the data-hook would have a bad name.
There was a problem hiding this comment.
If I got it correctly, I think this div should go into the if statement. I think it will still be evaluated even if the if statement is false, since Deface should do its magic before the erb is rendered.
There was a problem hiding this comment.
My thought here was that someone may have a deface customization that's adding non-password related fields here simply because it would be a convenient place to add more user fields. I'm fine putting the div into the conditional statement as well, but I think that may cause customizations to be hidden unintentionally if people are using this data hook for non-password stuff.
There was a problem hiding this comment.
I think that if someone is adding some non-password related fields into the password dedicated div it's ok to make this change, we can't handle every scenario. The problem is if someone is using this hook in the insert_after or insert_before deface action, which is legit and the added parts will be hidden at that point. :(
That said, your solution is probably the safest one in terms of backward compatibility.
JDutil
force-pushed
the
fixes-438
branch
5 times, most recently
from
d7e3ca2 to
6fc62e3
Compare
|
@tvdeyen a button to send a password reset email was added to solidusio/solidus_auth_devise#146 I can modify this to work based on permissions though. |
JDutil
force-pushed
the
fixes-438
branch
2 times, most recently
from
1b006f3 to
edd342a
Compare
JDutil
changed the title
|
@tvdeyen updated to be permission based 👍 |
|
@tvdeyen Yeah I also think it'd be great to start shipping Solidus with some sort of customer service role. Giving every "admin" super user permissions is a bit much by default. That would also help for testing many permission related features. |
For security purposes administrators should not be able to set a users password. Only the accounts owner should be able to directly set their password. administrators should only have the ability to send a password reset email to the account owner. Otherwise someone working in customer service or another role could take over a users account in order to make illegal purchases with their stored credit card information. In order to maintain backwards compatibility, and leave more power in control of the store owner this will leave the current admin role behavior the same, but anyone creating custom roles will no longer be able to update passwords unless they explicitly add a change password permission.
For security purposes administrators should not be able to set a
users password. Only the accounts owner should be able to directly set
their password. administrators should only have the ability to send a
password reset email to the account owner. Otherwise someone working in
customer service or another role could take over a users account in
order to make illegal purchases with their stored credit card
information.
In order to maintain backwards compatibility, and leave more power in
control of the store owner this will leave the current admin role
behavior the same, but anyone creating custom roles will no longer
be able to update passwords unless they explicitly add a change
password permission.
Fixes #438
Checklist: