After masquerading as a user, that user's last access time changes, as seen on the People list. An admin should be able to masquerade as a user without it registering as an access by that user.

Comments

dankoB created an issue. See original summary.

glynster’s picture

Agreed, did you get any headway with this?

aclebson’s picture

Me too, do we have any news about this?

aclebson’s picture

Guys, forget about "last access", you can use the data "login" to know when the user made the last login, I mean, that data is updated just by a real authentication.
Cheers

glynster’s picture

@aclebson you rock-star, made the change and it works perfectly for our needs!!

megachriz’s picture

Not overwriting the last access value might only be possible with hacking the 'session_write_interval' variable.

From _drupal_session_write() in includes/session.inc:

// Likewise, do not update access time more than once per 180 seconds.
if ($user->uid && REQUEST_TIME - $user->access > variable_get('session_write_interval', 180)) {
  db_update('users')
    ->fields(array(
      'access' => REQUEST_TIME
    ))
    ->condition('uid', $user->uid)
    ->execute();
}

So if we can manage to temporary set 'session_write_interval' to REQUEST_TIME upon masquerading, we might be able to prevent last access from being overwritten. I think it is safe to hijack this variable, in Drupal core I only see this variable mentioned in _drupal_session_write() and in an automated test.

megachriz’s picture

Status: Active » Needs review
StatusFileSize
new1.51 KB

I think that this patch will do the trick. At least it does with my initial testing.

I tested the patch myself in the following way:

  1. As an admin user, went to /admin/people.
  2. Went to the page of a particular user.
  3. On its user page, clicked the masquerade link.
  4. While logged in as that user, clicked around for a few minutes.
  5. Clicked the switch back link.
  6. Verified on /admin/people that the last access timestamp hadn't changed.
  7. Verified that the last access timestamp for my own user account did update after switching back.
mrcharles’s picture

@MegaChriz - Good man...this patch worked a treat for me too. Thanks.

possibri’s picture

Thank you!

izmeez’s picture

@mrcharles & @possibri Can either of you change the status to RTBC?

possibri’s picture

Status: Needs review » Reviewed & tested by the community
andypost’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/masquerade.module
@@ -50,7 +50,7 @@ function masquerade_permission() {
+  global $user, $conf;

@@ -68,6 +68,10 @@ function masquerade_init() {
+    // Set 'session_write_interval' to REQUEST_TIME to avoid $user->access from
+    // being overwritten.
+    $conf['session_write_interval'] = REQUEST_TIME;

nice workaround, but to be commitable it needs configuration

andypost’s picture

Title: Last access by a user should not change after masquerade as that user » [D7] Last access by a user should not change after masquerade as that user
ressa’s picture

Status: Needs work » Closed (outdated)
Related issues: +#3042321: Last access by a user should not change after masquerade as that user (D8)

Thanks for reporting this. In an attempt to help the maintainers, I am going through some of the Drupal 7 issues, and closing them, since Drupal 7 is EOL.

Maintainers should grant credit for the great work to the relevant users, even if the patch did not get committed: https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett....

This was fixed in modern Drupal via #3042321: Last access by a user should not change after masquerade as that user (D8).

Since Drupal 7 is EOL, we can probably close this issue, but feel free to re-open if this is still relevant.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.