Error out when trying to masquerading as blocked user

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

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.

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.

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?

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

The patch from #6 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...

So after 4 years a bug is still here. There's a simple solution: DO NOT allow to found blocked user. Just hardcode a filter over request.
What's wrong with this "minor" bug: when you step on it, you will be thrown out of AMDIN session, not the user you tried to masquerade.

Hi, its still here another 3 years later :p.
Sometimes I pick a random user to see how a page looks to non-admins, and just get logged out.

New patch applying to current 7.x-1.x-dev and 7.x-1.0-rc7

Includes:

• Require users.status = 1 in masquerade_autocomplete() and masquerade_autocomplete_multiple(), so you do not get any blocked users via autocomplete.
• Validate user's status in masquerade_block_1_validate(), so you will get a form validation error if you entered a blocked user.
• Check user's status in masquerade_switch_user().

I do not think that we need to log to watchdog (above patches did).

I have one question: the other patches checked user's status like:

if (!empty($new_user->uid) && empty($new_user->status)) { ... }

What's the purpose of !empty($new_user->uid) &&?
My patch just checks empty($new_user->status).