If I masquerade as a user and then navigate to account details and change that user's password it appears I am no longer masquerading but am actually logged in as that user. Trying to go to /masquerade/unswitch at this point does not work.

Comments

deviantintegral’s picture

Version: 5.x-1.2 » 6.x-1.x-dev

This is caused by the session being regenerated when the password is changed. I think the best solution is to implement hook_user, save the sid before the password is changed, and then update the session after a new one is generated.

Or, we could add a note that changing the password will prevent switching back for security purposes. Or, disable password changing completely.

deviantintegral’s picture

Status: Active » Fixed
StatusFileSize
new1.29 KB

Here is a patch which fixes the issue by storing the old session ID and updating the {masquerade} table if the sid is changed. I'll be committing it shortly.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

tsmacdonald’s picture

Status: Closed (fixed) » Active

This is still an issue; reopening.

leex’s picture

I also have this issue. The above patch is very obsolete.

leex’s picture

Assigned: Unassigned » leex
Status: Active » Closed (fixed)
StatusFileSize
new1.5 KB

Here is a patch against 7.x-1.0-rc5

This should keep you masquerading when you change passwords. I'm not sure of the implications of such functionality but this is the minimum code to make the masquerade persist when a password is changed.

Maybe the maintainer can take a look and if this sort of functionality is safe then I could roll a patch against 8.x or 7.x-dev?

andypost’s picture

Status: Closed (fixed) » Needs work
+++ b/sites/all/modules/contrib/masquerade/masquerade.module
@@ -457,6 +457,16 @@ function masquerade_user_submit(&$form, $form_state) {
+    global $_masquerade_old_session_id;

@@ -478,17 +488,17 @@ function masquerade_user_update(&$edit, $account, $category) {
+  if (!empty($_masquerade_old_session_id)) {

using global here is weird, maybe better to try set the some value on user object?

leex’s picture

andypost I would agree but it's already global on masquerade_user_submit so it seems natural to use the same variable for this use case. This way we don't have to add extra code to include global user and then check for that in separate test when we are already testing for $_masquerade_old_session_id in the same script.

avpaderno’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)

I am closing this bug report, as Drupal 6 is no longer supported. Please re-open it if the issue is still relevant for the Drupal 7 or 8 version of the module.