Module Weight is set to 1000 which can break SSO when initially visiting a site on a secured page. The authentication might take place after the page has already been denied to the user.

To reproduce the error (Both sites must have crowd configured and be sharing login tokens):
1. Login to site A
2. Visit a secured page on site B.
3. Access is denied on site B but the user is logged in. (Show the login status on the 403 page to verify this).
4. Refresh the same page or visit another secured page and the user will see the page as intended.

To resolve the error:
Change the module weight to be the first executed module. Such as -1001.

CommentFileSizeAuthor
#1 crowd_956110.patch720 bytesben.bunk

Comments

ben.bunk’s picture

ben.bunk commented
Status: Active » Needs review
StatusFileSize
new crowd_956110.patch720 bytes

A Patch for the install file.

ebeyrent’s picture

ebeyrent commented
Assigned: Unassigned » ebeyrent

I had originally weighted the Crowd module for a reason, which escapes me atm. I'm concerned that setting the module weight in the installer probably wasn't such a great idea, as it clearly doesn't work for all use cases.

I'll poke through my notes to see if I can recall what prompted me to set the weight in the first place.

ben.bunk’s picture

ben.bunk commented

For a memory jog: Did this have anything to do with how the ldap modules integrate with crowd? I haven't tested this to verify but it seems possible.

ebeyrent’s picture

ebeyrent commented

Most likely... :o)

greg2010’s picture

greg2010 commented

I am experiencing a similar issue using Crowd with numerous sub-sites in an Aegir platform. I have set the crowd module weight to -1001 in the system table. It has the lowest weight in the table. When users leave the parent site page to view a sub-site, it does not automatically keep them logged in.

ben.bunk’s picture

ben.bunk commented

Greg2010 your issue Sounds more like a cookie domain problem then this issue

rjacobs’s picture

rjacobs commented
Title: Module Weight » Module weight very high - breaks some login workflows
Version: 6.x-1.2 » 7.x-2.x-dev

I can confirm that this is also an issue with the 6.x-2.x and 7.x-2.x branches (which are the much more active branches at the moment). I'm going to mark this against those v2 branches and take a look.

rjacobs’s picture

rjacobs commented
Status: Needs review » Closed (duplicate)

So this problem is probably due to the order in which hook_init calls are made. I suppose that Drupal, or some other modules, may force an access denied error before the Crowd module can finish it's SSO business. Because the module weight is so high at the moment (meaning later execution relative to other implementations of hook_init), pretty much all the other init stuff is happening before crowd can do anything. In addition, crowd sso checks never happen for cached page requests, which further limits crowd's ability to do it's SSO magic on all requests.

Anyway, I think that all this will be addressed once a fix for the following issue lands:

#1968994: SSO checks should probably run in hook_boot

Fixing that will mean that the SSO checks will happen in hook_boot, which will always be before hook_init. For this reason, I'm going to mark this as a dup of #1968994.