Session won't read if user is blocked.

Ends up logging out current user but with message saying now masquerading as.

Comments

Status:Active» Needs work

How come you didn't pair the watchdog with a dsm?

StatusFileSize
new819 bytes

Copy and paste from another error condition where there is no drupal set message.

Status:Needs work» Needs review

StatusFileSize
new5.33 KB

Hefox's patch is a good start. I've rerolled it for the dev branch and added some code to remove menu items and quick links for blocked user accounts and to filter blocked users out of the options presented by the autocomplete fields in admin/settings/masquerade and the masquerade block. If this meets with everyone's approval I'll open an issue and roll a patch for D7.

Version:6.x-1.4» 6.x-1.x-dev
StatusFileSize
new10.34 KB

I've rerolled this patch against HEAD. I also fixed a few minor issues. The attached patch contains:

a266968 Issue #932814: Prevent switching to blocked user accounts.
d945e9a Issue #932814: Fix minor code style issues.
609f06b Issue #932814: Don't deny access to a page when unable to switch accounts.
4aa3823 Issue #932814: Fix typo in dsm() when removing a blocked account from the list of quick switches.

I'll be working on a 7.x version in a moment.

Version:6.x-1.x-dev» 7.x-1.x-dev
StatusFileSize
new14.13 KB
new15.02 KB

Here's a 7.x version of the patch. I also fixed an issue with the user admin form not properly handling removing blocked users in both versions.

is this still an issue?

Status:Needs review» Needs work

This is still a bug (for 7.x-rc4)

The patch from #7 looks ok but I guess is probably not applicable anymore.

+++ b/masquerade.module
@@ -757,6 +786,14 @@ function masquerade_switch_user($uid) {
+  ¶

Whitespace

Suppose we should not loose data on status change.
This check should be done as #2 and additionally clean-up Quick switches on render.
In case of form we just need to throw error message

Just throwing in an additional idea in here.

What if a situation occurs where someone wants to masquerade as a "blocked" user; but wants to restrict this functionality to a handful of trusted accounts?

Would an additional permission make sense? Is this a realistic scenario?

Those that don't have the permissions applied would see the error page; those that do, would be able to masquerade as the blocked account.

#10: if a user account is blocked, it cannot be logged into, hence what is there to check? There is no scenario as there is no way to get into that user account during blocked state, and Masquerade would only receive the default error message you get if a login fails...

Since session handling can be overridden (memcache for example), it's possible to override the inability to login to blocked users.. but wow, that'd be bad. Don't think masquerade should support that extremely specific use case.