Change shib_auth module weight to give it higher precedence to avoid login issues

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):

          //Hack to invoke hook_user and set DRUPAL_UID cookie
          if (module_exists('boost')) {
          	boost_user('login');
          }

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

    if (module_exists('boost')) {
    	boost_user('logout'); 
    }

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...

I just tweaked the MySQL table and has improved login via Shib

I was also able to change the weight in the {system} table for shib_auth and fixed the delayed permissions issue. It would be great to have this patch applied to a module update.

I confirm #14 works

Thank you for taking care of this. Could you please test if the 4.x-dev version works without patching?

Thank you.

+1

I ran into this issue while upgrading to the 6.x-3.3 branch as well. Updating the module weight to -20 fixed it.

I have this same problem, user logs in clicks on private content gets "access denied" hits refresh then is granted access, but changing the module weight does nothing. I am not running boost but I am running shib 6.x-4.0-rc6.

Any ideas?

I see same issues on Drupal 7 installs with shib_auth 7.x-4.0-rc3. Changing module weight does not help ...

Attached patch (while not very well tested ... and probably could/should be implemented differently) seems to solve the issue .. at least for me (we do not use the shib_auth_custom_form_url .. not sure how it would behave with ..) Note: I checked this on Drupal 7, but shall work on Drupal 6 installs too..

Changing the weight doesn't do it for me. I have tested Jarek Polok's patch and it works well if the user already have an account. However if the user is registered upon login the access denied message shows as before. And if DEBUG mode is enabled the $user array is not shown in the print. The next time the user logs in the access denied message is not shown.

Are you experiencing the same thing with your patch Jarek?

Hi

> Are you experiencing the same thing with your patch Jarek?

Not really - but this patch it is far from being perfect and just solves - or rather provides a workaround for - the problem in our env. .. I guess this will depend on many settings you have for shibboleth (lazy vs. strict sessions we use) and shib_module (account linking, user defined usernames / e-mail - which we do not use) .. etc.

For me it works all the time - except 'Notice: Undefined variable: _SESSION in shib_auth_debug() (line 176 of /SOMEWHERE/sites/all/modules/shib_auth/shib_auth.module).' for http sessions (but this is again our setup I guess, we prevent auth via http alltogether and redirect to https for auth users).

Cheers

Jarek

+++ shib_auth.module	2011-07-29 09:25:58.431404000 +0200
@@ -429,7 +429,13 @@
+    global $base_url;  ¶

Remove the trailing whitespace.

+++ shib_auth.module	2011-07-29 09:25:58.431404000 +0200
@@ -429,7 +429,13 @@
+    $destination=user_login_destination(); ¶

Again, remove trailing whitespace and need spaces around the variable definition and value.

+++ shib_auth.module	2011-07-29 09:25:58.431404000 +0200
@@ -429,7 +429,13 @@
+    if (is_array($destination)) { $destination=$destination['destination']; } // Drupal 7, must be better way of doing this...

This does not adhere to the Drupal.org code standards. The if statement should be on its own line, the variable needs spacing before and after the equal and the bracket should be on its own line.

+++ shib_auth.module	2011-07-29 09:25:58.431404000 +0200
@@ -429,7 +429,13 @@
+    drupal_goto($base_url."/".$destination);  // drupal_goto changed between 6 and 7 .. I'm too lazy to make an if...

The concatenation should have a space on either side of the periods.

+++ shib_auth.module	2011-07-29 09:25:58.431404000 +0200
@@ -429,7 +429,13 @@
+  } ¶
+    ¶

Remove trailing whitespace.

Please refer to http://drupal.org/coding-standards and resubmit the patch.

Hello,

Please see:

http://drupal.org/node/1279186#comment-5111882

the patch attached there seems to solve that problem...

Jarek

Anyone has any idea, which module causes our module to not work perfectly? I keep trying to reproduce the issue, with no luck. Do you use isPassive, or any booster / aggressive cacher module?

No we do not use isPassive, but we do use memcache.

Please try latest dev, possible solution is described at #1279186: Roles not always assigned . Feel free to set to needs work, if it didn't solve this issue.