Hello,

I am trying to understand how this module works, but I don't quite get the idea looking at the code, so I beg for an elaboration about the communication process and the management of cookies/sessions that happens behind the scenes.

As far as I can understand, the "hook_boot" at the client checks for the existence of $user->global_id, and if it does not exist, it makes a request to 'sso/associate' at the master. The master creates a new entry in the {sessions} table with a new random sid, and in the global_uid column it writes the current master's session_id() [WHY?]. It follows by doing $_COOKIE[session_name()] = TRUE, which I don't quite understand.

The master redirects to the client's 'sso/claim' path, which in turns tries to read a {sessions} row with the nonce value, and this query is expected to find the new entry just created at the master using sess_write inside the 'associate' function.

Then it destroys its current client session, uses session_id() to assign the sid of the found {session} table's row, (which is the new random sid generated on the master), and calls 'sess_regenerate'.

The function 'sess_regenerate' creates a new sess_id and updates the correspondig {session} table with two UPDATE queries. The first one changes the sid column of the old session (which now is the session row created by the master using sess_write) to the new sess_id, and the second one (which is a new addition of this module), updates the global_id column with the new sess_id.

Although I can understand (I hope) the flow that is happening, it does not seem to be correct in my opinion. because I can not understand how the global_id column is assigned to the global $user at the client.

Inside the "claim" part, when we do "session_id()" and afterwards "sess_regenerate", this implies that the sid column gets updated but not the global_id, because sid and global_id hold different values. How this can be explained ? Besides if you keep an eye on the sessions table, I can never see a "global_id" value that persists, in my experience this column is always empty, except for the very first time when you visit a page as a non-logged in user.

I am looking forward to your help.
Thank you very much for this module.

Comments

yonailo’s picture

yonailo
He/him
commented

Hello,

I have found out what my problem was. I was experiencing always the same behaviour, i.e: associate -> claim on every page request.

The problem was caused by the "og" module, which has this piece of code:

function og_init() {
  // We have to perform a load in order to assure that the $user->og_groups bits are present.
  global $user;
  if ($user->uid) {
    $user = user_load(array('uid' => $user->uid));
  }

So on every page request, the $user->global_sid was deleted, because the function "user_load" does not return this field.

I have modified this piece of code as follows:

function og_init() {
  // We have to perform a load in order to assure that the $user->og_groups bits are present.
  global $user;
  if ($user->uid) {
    $global_sid = $user->global_sid;
    $user = user_load(array('uid' => $user->uid));
    $user->global_sid = $global_sid;
  }

And now things are working properly.

This issue might be related to the devel_switch_user funcionality not working, as this function also overwrites the global $user with the result of a "user_load", which like in this issue implies that the global_uid is going to be lost, but this needs further investigation because as far as I can understand this would be the intended behaviour, because when changing of uid the session should be dispatched throught the SSO process of associate -> claim for the new userid. I am missing something stupid here.