If you have used the devel module, you'd probably know about the nifty Switch user tool that is available as a block for use in a site. It allows users with the required permission to switch from the block as any other user.

This is the API doc for the devel_switch_user method.

I notice that while switching between users, the session ID of the user as whom you initially logged in to the Drupal site for the first time is re-used for all switched users i.e. In {sessions}, the uid column is simply changed while {sessions}.sid or {sessions}.ssid persists.

A problem with this approach is that the session data ({sessions}.data) (saved using the $_SESSION superglobal) remains the same even for switched users which isn't good to test the application logic sometimes (at least not in my case).

Is there an elegant way to clear the session data of the old user on switch? If not, how can this be solved?

  • Clearing $_SESSION data may break things. I would advice not to do it. If you have to, you have to provide us a list of modules that may write to it - but then I don't believe anyone would make a full review of them, one after one. Is alternative solution acceptable?
    – Mołot
    Jul 8, 2013 at 12:28
  • Perfectly fine with an alternate solution. But could you give me an example of something that'd break if I clear session data. Isn't Switch user supposed to mimic user log out + log in which in turn mean destroying the session in the traditional sense right? Jul 8, 2013 at 12:44
  • Switching user would be perfectly all right. It's just switching back what may be broken - module would be free to expect some data in $_SESSION and that data would simply not be there anymore. Any chance to refactor your modules so they would use proper Drupal storage? If so, I can provide answer how.
    – Mołot
    Jul 8, 2013 at 12:46
  • Sure. Open to refactoring. Jul 8, 2013 at 12:51
  • So consider rephrasing your question to something like "How to avoid data collisions when switching users?" - purging $_SESSION would be only one of answers then.
    – Mołot
    Jul 8, 2013 at 13:05

1 Answer 1


Problem is - $_SESSION was never really meant as temporary data storage. Proper and safe way is to use cache_set() to store data.

First argument, $cid is customary used as a string with sections separated with :, so in your case it should look about like that:

global $user;
// ...
cache_set('mymodule:' . $user->uid . ':' . $user->sid . ':kind_of_data',
          $data, 'cache', CACHE_TEMPORARY);
// ...
$data = cache_get('mymodule:' . $user->uid . ':' . $user->sid . ':kind_of_data',

That way you will allow Drupal to benefit from database permanency, memcached speed, whatever you please. And by including uid of current user, you are sure data is well separated and no collisions will occur. Including session ID allows proper anonymous user handling. For logged in part $user->sid might be safe to ignore, depends if you want data to be shared between logged in seats or not.

If you use session id as a part of cache key, like above, entries will be only valid for one session. If your site has few users, obsolete cache entries are not a problem. And if you have many, you should store both sessions and cache in memcached, apc or similar technology anyway. Database is simply to slow for this. Memory based cache engines are very good at automatically destroying unused entries when needed, destroying them from code is a waste of time and effort.

  • Looks good. Only that the type of information I'd like to store is heavily session-dependent. Eg. Imagine Has the SSO for this user been done for this session yet? Entries in {cache} are cleared on the normal cache wipe - however, in this case, I will want to clear only those cache entries whose sessions (from the session ID in the key) have expired which could also make it slightly more complex. Jul 9, 2013 at 3:24
  • @AmarnathRavikumar Answer updated. Long story short, it's not a problem. Don't reinvent the wheel, no need to.
    – Mołot
    Jul 9, 2013 at 7:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.