Closed (fixed)
Project:
Masquerade Extras
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
4 Jul 2012 at 14:07 UTC
Updated:
19 Jul 2012 at 22:21 UTC
Jump to comment: Most recent file
Comments
Comment #1
mrfelton commentedPatch against latest code in the 7.x-1.x-rules branch, and using masquerade-7.x-1.x
Comment #2
mrfelton commentedAlso, the function should not be expecting a value by reference, as that is not what Rules will pass to it. Updated patch resolves that.
Comment #3
wjaspers commentedI'm not sure that I trust this. Its possible if another module comes along and sets this value to
nullor the session hasn't been written yet (and the value 'cleared'), that we could get a false positive.Another reason (I think) I originally went with the following code, is that I could detect if someone other than themself was masquerading.
Otherwise, this looks good.
Thanks for all your feedback/patches, too!
Comment #4
mrfelton commentedBut what is $user->masquerade_account ? I couldn't see this being set anywhere at all.
Comment #5
wjaspers commentedHmm. I went hunting for it, and can't find it now. Maybe the environment I had going was doing something that attached it to the user. (It was awhile ago).
Studying the code again, I think checking the
$_SESSIONwill be ok.although an "empty()" check may be more appropriate than "isset()".. EDIT: I forgot about "anonymous", which empty() would match "0". So ... isset() is correct.I also see another mistake I made, wherein we're checking the current user account against the database, instead of the account passed into the function.
Comment #6
wjaspers commentedPer the prior patches you provided and the above comments:
http://drupalcode.org/project/masquerade_extras.git/commit/9fbe725131e05...
I tried to attribute the patch to both of using git's notes feature (see http://groups.drupal.org/node/161659), but I can't tell if it did anything.