Posted by bajnokk on July 2, 2009 at 4:09pm
| Project: | Shibboleth authentication |
| Version: | 6.x-3.3 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
The module does not work with caching enabled. For normal caching, the user has to hit the reload button, but with aggressive caching, it fails constantly.
At least it is now documented...
Comments
#1
Adjusting priority to be align with the Issue queue handbook. However we take this bug very seriously.
#2
We have encountered this as well.
We would like to add our +1 to requesting this be addressed.
Thanks!
#3
After looking around, I was able to SOMEWHAT Fix this.
Inside the Shibboleth Coding, around line 307 (after I edited at least), you will see the variable declaration of $actuallocation.
I was able to change this, KNOWING I was redirecting after the shibboleth.
$actuallocation = urlencode([Everything until ://] . '://direct.to.me'; // Got rid of wayuri or whatever else was here.
I then deleted ALL of the Caching and Cookies in my browser, and Shibboleth worked with memcache enabled. I am sorry if this wasnt too descriptive, but I am unable to access the actual file to copy/paste the code. But, this code actually worked with memcache, GIVEN the cache/cookies were deleted on the browser after the caching was turned on (also, i cleared drupal cache right after I turned it on just as a precaution).
Hope it helps someone else...
#4
Hi!
I am an official devenloper this module and I created a patch for the lastest dev version.
I think this patch SOLVE the caching problem both normal and aggressive cache.
The patch includes the more useable improved debug feature too.
Please review it!
If this patch is slove this issue we will release a new stable version.
#5
I've found an issue with the patch provided:
When the url of doesn't end with a slash, the resulting url doesn't work. This is the case for example with a multilingual site, where url('<front>') resolves to e.g. '/en' for english or '/nl' for dutch. Appending a / if needed seems to solve the problem.
$front = url('<front>');
if (substr($front, -1) != '/') $front .= '/';
//$actuallocation: the path where the Shibboleth should return
$actuallocation = (isset($_SERVER['HTTPS']) ? 'https' : 'http')
.'://'. $_SERVER['HTTP_HOST']
. $front
. $url_prefix
.'shib_login/'
. $_GET['q'];
#6
I've been running the patch with the slash-adjustment in my previous post for a while now and haven't encountered any issue related to caching.
#7
I tried applying the patch to latest DEV (1 Oct 09) and it failed. So then applied patch to 3.1 - which passed - but did not cure the caching problem for me. 'Login' style link remains on previously cached page.
What is the status of this patch against DEV?
#8
Using the /shib_auth/ caching workaround currently in DEV, I've encountered a few double slashes in the generated URL. Rather than use the link generated by the module to login with Shibboleth, I generate a custom login link (I don't want users to be confused by the conventional login texfields, and most of them will have no idea what 'Login with Shibboleth' means). So I've got my own functionality in template.php > preprocess_page which goes along the line of:
function theme_preprocess_page(&$variables) {
global $user;
global $base_url;
//get drupal site root and add trailing slash if not there
$siteRoot = $base_url;
if (substr($siteRoot, -1) != '/') $siteRoot .= '/';
// Create a custom variable to store the member login link, if the user is not already logged in. In page.tpl.php, remember to 'print $member_login;' in the right place!
if ($variables['logged_in']) {
$variables['member_login'] = l(t('Logout'), 'logout', array('attributes' => array('class' => 'memberLogin', 'title' => 'Log out from the system. Note you may subsequently need to close your browser to completely log out from all University online services.')));
$variables['member_account_link'] = l(t('My account'), 'user/'.$user->uid);
}
else {
$variables['member_login'] = l(t('Login'), $siteHome.'Shibboleth.sso/Login?target='.$siteRoot.'shib_login/'.$_GET['q'], array('attributes' => array('class' => 'memberLogin', 'title' => 'Log in using University online ID')));
$variables['member_account_link'] = '';
}
}
So I don't see a reason to use PHP urlencode (mentioned at #3 in #543602: The return location should be encoded); and is there a problem with using $base_url to get the site root (after all, shouldn't we be using all the Drupal functions and variables for 'safe' code)? The current DEV Shib module also assumes that $front is the site root too, which I think is an incorrect assumption.
This issue is also related to #442170: shib_auth incompatible with caching (even normal mode).
#9
@#7: No, the -dev (and 3.2) already contains the fix
@#8:
* I've opened a new bug for the double slash problem: #608358: Get rid of double slashes at the return url
* I've opened a new feature request for overriding the login link #608364: Allow customizing login link (about to be fixed in 4.x)
* We don't want to use templates at the moment, so this will need manual coding if you need more that just changing the login link
* You can get rid of the login form elements
** on the front page by disabling the user login block
** on the logged-in user page: use the userprotect module
** on anonymous /user page: we don't want to hide the conventional login textfields, because this is the only way the admin can log in while using the module
* I've opened a new bug for the $base_url misinterpretation #608368: Misinterpretation of $base_url
#10
snorkers: did you ever find a solution to your cache/login problem? I agree that the patches and such do not improve the situation. I am also not using the login block, as it doesn't make sense for our site. Instead, we provide a login link when Access Denied error is encountered. I really don't like the idea of forcing people to visit an uncached page rather than their original destination. Just looking for more usable solutions...
#11
@seattlehimay I kinda improved things by preventing local [browser] caching, by inserting following into HEAD of page.tpl.php:
<meta http-equiv="cache-control" content="no-cache" /><meta http-equiv="pragma" content="no-cache" />
Which puts more load on my server, but should almost guarantee that every page request is served from my end.
And I'm also running with my own login link generated on each page (mentioned above), so that the user effectively returns to the page they were originally on. I have modified the technique rolled out in 6.x-3.3 where the /shib_login/ is inserted in the target URL to circumvent the caching problem:
SITE_ROOT/Shibboleth.sso/Login?target=SITE_ROOT/shib_login/ORIGINAL_PAGE. I also bumped the weight of the shib_auth module up directly in MySQL (see #627958: Change shib_auth module weight to give it higher precedence to avoid login issues for more detail). But I reckon I'm still getting about a 5-10% 'failure' rate, where is a user is returned to their original page as an anonymous user.One fact that seems consistent is... if a freshly-logged in user is returned to a page as an anonymous user, if they wait for 60 sec, then refresh, the [correct] authenticated user view of a page is shown. No idea why, but that may be a clue to the problem. Not a great UX though, asking users to wait for a minute.
I've looked at the Shib code loads of times and it looks simple and correct; but to be honest, I feel as though I'm stabbing in the dark a bit now, as if the conventional Drupal login is used (and Shib is bypassed), then this problem never occurs.
#12
It's fixed in 4.0-rc1. (Hopefully. That was done very long ago, and unfortunately I can't point to a specific commit fixing it.)