Session is not initiated upon login, only assigned after clicking on a link

Ok, so the following:

[session] => authentication|s:9:"shib_auth";

is missing from the USER variable until we click on a link. Now to uncover how to get it in there properly.

well the roles show up in the user variable, so I guess the roles are there, but Drupal thinks that it is still dealing with an anonymous user. Ugh, is this perhaps some problem with the roles not getting assigned until after the page load?

Is anyone able to reproduce this behavior?

To reproduce: Enable shib_auth module, set the settings for role assignments, uncheck the node permission for 'view content' for anonymous user if it is checked, check it for authorized user. Login. Do you receive a 'Not authorized to view this page...'? Try clicking a link, then everything shows up normally.

I am also having a problem with panels, the permission checks for them are not working if one assigns a permission check for a role, then the check returns false because shib_auth doesn't seem to be actually assigning the roles (they show up in $user->roles, but as far as Drupal is concerned they aren't there). The same is true if I create a permission and then check that role to have that permission and try that in panels, still no dice.

Anyone able to reproduce this?

Just to note, in this setup, one goes to Drupal, is redirected to a shibboleth idp link outside of Drupal, logs in, and then is redirected backto Drupal (as opposed to using the block within Drupal to login). So perhaps that is causing some issues? But again, all the $_SERVER vars are there and the roles show up in $user_roles.

I've just stumbled across this, as I had to configure my site to using Boost to serve up cached content to anonymous users. I have a few conventional Drupal login accounts that are fine and show non-cached pages (etc) for such authenticated users; however, logging in via Shib, I see exactly the problem outlined above - not only are access privileges not recognized, but they are served up static content cached by Boost. Until a random link is clicked on then all appears well.

A suggestion at #635864-2: Boost with Shibboleth (I had thought it was initially a Boost problem, but it looks to be a Shib issue) is to implement module_implements() but it's not clear that Shib is.

Subscribing.

OK a little more playing with different browsers and some of the features that appeared in release 6.3 of shib_auth...

Merely clicking on another link does not address the problem - generally you are still being treated as an anon user if you are viewing a previously cached page (regardless of caching method). I've tried various MS and Mac browsers and results are inconsistent. The biggest spanner in the works is Firefox, as I'm convinced it does some local (client side) caching itself. It's hard to see a pattern but this is what I've noticed:

• After logging in with Shib, then viewing a previously cached (or not) page such as www.example.com/about you are treated as an anon user. If you go to www.example.com/shib_login/about, the cache clears, you are redirected back to /about and you are treated as a grown up. However, if you go to other pages immediately, sometimes pages are still rendered as for anon users.
• Sometimes if you click around on a few pages, after about 60 seconds, you start to get pages served up as an authorized user
• Sometimes if you go to www.example.com/user you then initiate your logged in session and things generally work fine - although sometimes you have that 60 second wait
• Generally don't see the above behaviour when using conventional Drupal login

Err... that's it for the moment, but it all still feels a little random to me. Is there something client-side we should be monitoring? Are there tools to look at cookie/caching activity live in different browsers?

Sorry more questions, but I feel like I'm stabbing in the dark a lot.

Even more playing around - I've finally found a hack for shib_auth.module to get it to work with Boost. The problem was that a cookie used by Boost (DRUPAL_UID) wasn't being set during shib_auth_init() (which is called on every page load). Without this cookie being set, Boost serves up cached content. So you have to add in a little call to boost_user() everytime that shib_auth_init() acknowledges a valid/new user (in the lines user_external_login_register($uname, "shib_auth");  $_SESSION['authentication'] = 'shib_auth'; ). So I inserted the following code (around lines 112, 144, 171):

As an added safety net, I also added the following code under shib_auth_user() function > logout condition (around line 241):

What's odd is that even with a [Boost] cache life of 24 hours, and the above hack not being implemented, after a minute or so of clicking on random links or page refresh, the cookie DRUPAL_UID would eventually appear (and so user would appear logged in) so I'm not sure if hook_user('login') is getting called somewhere else... and maybe this is the root of the problem that others are seeing. There's a bit of detail about external login in 'Pro Drupal Development 2nd Ed' pp129-135 for those that know such things: the flowchart indicates that hook_user($op='login') should be called during external login, but I've no idea what's going on in the module (not that the code's bad - my knowledge is just not up to spec).

If I knew more about hook_user (and hooks in general) I'd be able to come up with something more conclusive. And I'm still not sure about client-side browser caching either... Hope this observation triggers more insight...