If you are supporting SSO with Bakery (or similar code), masquerade will not work. The masqueraded user will be denied access because the persistent id info (Cookie in Bakery's case) will not match.
These actions generally take place when hook_boot() is called.
It is hard to add code to a hook_boot() implementation that identifies a masquerade user switch because the session flag is only set in the masquerade_init() process... after the boot() process. In other words:
- Masquerade user is selected
- Next page loaded is loaded: SSO Boot process checks for $_SESSION[masquerade], doesn't find it and denies user
- Masquerade_init() not called to set session flag
Currently, IFAIK, the only work around for this is to modify your SSO code to duplicate the masquerade init code and double check for masquerading users. Very inefficient since the DB calls are made twice... and you may need to query the system table to see if masquerade is installed.
If masquerade_switch_user0 where to set the session flag and masquerade_switch_back() unset it, the the session flag could be used by boot() implementations to manage masqueraded users. This would be much more efficient since no DB calls would be needed... e.g. just do something like:
if ( isset($_SESSION['masquerade']) ) // don't check persistent data
An alternative to this would be to add a couple of masquerade API hooks that get called with users are switched. This would allow implementations to do any additional user setup / teardown needed by other modules.
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-6.x-allow_SSO_boot_to_identify_masquerading_user-1813696-1.patch. Unable to apply patch. See the log in the details link for more information. View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch masquerade-7.x-allow_SSO_boot_to_identify_masquerading_user-1813696-1.patch. Unable to apply patch. See the log in the details link for more information. View