shib_auth incompatible with caching (even normal mode)

That last sentence should read:

The shib module probably needs to register a callback and have the login link return to that in order to reliably authenticate when page caching is enabled...

I have also ran into this issue, and hope it can be resolved sometime soon!

I have ran memcache with Drupal on normal to only find it to where I had to go to another link in the site, then click on the link BACK to the home page (not using the back button).

We have encountered this as well.
We also have memcached and APC.
The only way around it is to turn off Drupal caching.

We would like to add our +1 to requesting this be addressed.

Thanks!

I would agree with all the above. I've had to disable page caching otherwise the user is left with a 'Login' prompt in the corner - really confusing. Only problem now is that the site is painstakingly slow. Caching seems to affect lots of other Drupal modules (not just shib-auth), and I worry that there is not a simple solution - this issue's been critical for over 5 months and nothing has happened.

I'm not a PHP head, and haven't developed any modules, but if someone can give me a clue where to start (I'm not sure what #442170-2: shib_auth incompatible with caching (even normal mode) even means) I am willing to get the ball rolling. I would imagine that most others using this module are in education, so probably don't have a stack of money to throw at the developer... otherwise a 'whip-round' would be my solution of choice.

How does the conventional Drupal login work? That doesn't seem to be affected by caching, so why is Shib?

Please try it with the -dev version. Maybe I'll be able to issue a new release _very_ soon.

Just tried DEV - a slight improvement, although when it did work, the return page [on my D6 site] hung for a while - were the caches being emptied by shib_auth?

Also noticed that if a user logs out, then logs in while the Shib [2.2] session is still valid (mine's set for 60mins, so users in theory shouldn't see the IdP login screen if their session is still valid, and didn't close their browser), they are presented with pages as if they are not logged in (even though they are). Playing around with 'destroy Drupal session' didn't seem to change things either way.

I've noticed that some browsers are caching pages too. I know IE used to store quite a lot, but Opera seems to be going there too. This is probably a much wider issue for the Drupal community at large, however.

Just tried DEV - a slight improvement, although when it did work, the return page [on my D6 site] hung for a while - were the caches being emptied by shib_auth?

No, no cache flushing is necessary. The trick is to redirect the user to a page which is not cached.

However if it's not working reliably for you, please give more details so that we can sort it out.

Also noticed that if a user logs out, then logs in while the Shib [2.2] session is still valid (mine's set for 60mins, so users in theory shouldn't see the IdP login screen if their session is still valid, and didn't close their browser), they are presented with pages as if they are not logged in (even though they are). Playing around with 'destroy Drupal session' didn't seem to change things either way.

This is how Shibboleth SessionInitiators work when you invoke them (what you do when you click on the Login link).

I've noticed that some browsers are caching pages too. I know IE used to store quite a lot, but Opera seems to be going there too. This is probably a much wider issue for the Drupal community at large, however.

Sorry, I don't understand the problem. Does it affect logins?

Updated to DEV 1 Oct 09. One function of users that has been asked is that once they log in, they return to the page they were originally on. As this is a feature of Shib 2, my template.php sets the 'Login' link to /Shibboleth.sso/Login?target=$base_url.request_uri() (OK not literally that code, but using PHP/Drupal to grab current URL), so they are returning to their original page; I am not using the default Drupal login block (so not utilizing the 'Shibboleth login' link that the module creates). However, the original page [that the user was on when they clicked on the 'Login' link] is still cached on the server by Drupal (BTW ignore my earlier comments about local browser caching). So using the current DEV, the user is getting logged in, but returning to a page that still prompts them to log in. I know DEV works, as if I view a random page the logout link (et al) appears. I'm just trying to find a way not to confuse users and keeping them in control of where they are in the site.

So should I NOT be using the ?target='current page' argument, and finding another [un-cached] page for them to land on - eg their account page - and sacrifice a reasonable request for usability, or does the work you've been doing in DEV use some other strategy?

Thanks for your quick replies BTW @bajnokk - really helping a lot.

Ah, so you are modifying the login block!...
Well, you should not do this because the caching trick is to redirect the user to a non-cached page (/shib_login/node/XX) which has a callback registered thus not cached.

If you are redirected to the wrong page after the authentication, that's another issue. I think it should be working with cache enabled as well, but if you experience this behaviour, please file a *new* bug report about specifically this. (Before that, please have a look at the solution others proposed at #543602: The return location should be encoded, where you can help with trying the proposed change.)

@snorkers,
please have a look at http://drupal.org/node/508378#comment-2009558 . I think it might be a solution to your problem. Too bad that I simply forgot to add this correction to the commit :(

Having looked a little more at redirection via /shib_login/node/XX, this is a workaround to the caching issue, not a fix. The current DEV release has also not addressed the slash issue correctly: sometimes a double slash will still appear on one end of /shib_login/ in the redirection URL, resulting a 'page not found' error. So this workaround is not yet correctly implemented (there's a patch at #508378-5: Module does not work with caching (reload needed) but cannot be rolled against the current DEV) to solve the core functionality of this raised issue.

Also, the first time a user logs in and they return back to their original page, the current DEV process works great as the page reloads and is refreshed correctly, rendered as a logged in user:). This is still a great solution for 90+% of scenarios; however, if a user erroneously logs out, and wants to log straight back in again, I find that they are served up a page as an unauthorized user.

I'm not sure if anyone else is interested in checking this out (never sure if it is just me), but I think it's a little premature to mark this as fixed. Not trying to make life hard, but I wouldn't want this pretty significant issue buried until others have tried it out.

* See also #608358: Get rid of double slashes at the return url
* I'm not sure what's the problem with logout / login again scenario. After logout, the module redirects to the page specified in module config. On subsequent login, the user gets back exactly the same page. If there is a specific problem there, please open a new bug report, because it seems very little relation with the original issue.