403 after SecureSite login until refresh

I'm experiencing the same issue.

I started with a clean install of Drupal 6.14 and Securesite 6.x-2.3 was the first module I installed. I tested and everything worked as expected. As I installed later modules I began to experience the 403 error after logging in as described above, with a refresh being needed to show the page properly.

I'm fortunate that I had only spent a couple of hours on the site before encoutering this problem, so I will be able to start again and test thoroughly after each new module or configuration change. I'll let you know if I find anything.

I found a solution, but I'm not yet certain of the consequences. On my site I have securesite set to Always force authentication. I don't want any content accessible to anonymous users, and so naturally I denied anonymous users the 'access content' permission, however if I allow it the problem described above disappears. The securesite login is still presented when content is accessed and everything appears to still be secured by it - is this how it's supposed to work in this situation and is it entirely secure?

That doesn't solve the issue for me - general content needs to remain available by anonymous users in my situation. Removing the "Access content" permission would make that impossible. I want only a limited part of the site to be protected.

I started experiencing this problem today after installing Organic Groups. I've narrowed this problem down to Organic Groups itself. It's fairly easy to test:

1. Try to access secure content: Failure.
2. Disable Organic Groups, try to access secure content: Success.
3. Enable Organic Groups, try to access secure content: Failure.

What's strange is that the content I'm trying to access isn't even handled by Organic Groups, it's not even a node!

Looks like I'm having the same problem, with Organic Groups installed as well. Setting this issue to a bug report (rather than support request), as it looks like there's a problem with the combination of the two modules.

I can confirm that I'm using Organic Groups too. No problems with SecureSite before OG was installed, discovered the same issue after OG (and several other modules) were installed on site - seems we can pin it down to this one.

After doing a good bit of debugging, we think we have found the issue.

securesite_boot is doing a DRUPAL_BOOTSTRAP_FULL during the boot process. This ends up calling a lot of hook_init methods in several modules, some of which, like og (and admin, among others), expect to be able to check permissions and what not at this point. Unfortunately, securesite has not yet authenticated the user and setup the $user global. This means that all of these init hooks do not have the correct user information. Organic groups tries to setup its group context which requires figuring out which groups a user has access to and whether or not the current path is accessible to that user. This process goes through the Drupal Menu API which makes calls to several hook_access methods. Some of these end up returning FALSE which causes the menu API to immediately dump a 403. This problem is similar to other related bugs like no CSS on the admin pages if the "admin" module is used right after logging in through securesite for the first time. Admin adds the CSS to the page header only if the current user has access to the admin pages. It does this during it's hook_init which, in this case, is again being called before the user information is setup.

Unfortunately, solving this problem seems to be non-trivial as securesite needs several pieces that are only loaded and setup during a full bootstrap. Here are some relevant stack traces and code snippets:

securesite.module: securesite_boot: 103

We're still investigating this and hope to find a solution in the near future.

Well, we've come up with a preliminary workaround but it has some disadvantages and there's no guarantees it won't break horribly. Because of the way that the Drupal module system works and since the "user" module is not a boot module, an additional redirect is required after authentication for this to work correctly. As far as I can tell, a change to Drupal Core would be required to support manipulating authentication in the way that securesite is doing safely. Anyway, here's the diff and I've attached a patch that may work for you.

It's worth noting that we opted to use a different solution for HTTP Authentication to workaround the above disadvantages (mainly the requirement for a redirect) so this was tested fairly briefly.

The below patch is meant to be run from the securesite module directory:

I've applied the patch from #8 against securesite 6.x-2.3 and it seems to solve the problem for me. I'm yet to try it out with 6.x-2.4, but judging from the release notes I guess that should work fine...

I've now updated to SecureSite 6.x-2.4, and applied the patch. It still works as it should, except that it breaks cron.php from functioning through wget. This is the wget output (I've censored the URL and IP since they're private for the time being, it calls cron.php with the proper --user and --password credentials):

The file "node" contains the homepage of the site. I've also tried this with invalid credentials; this results in a proper 401 Unauthorized.

In a browser, first logging in to the site and then calling cron.php works fine. If cron.php is the first request of the session (or you log out right before calling cron.php), the same behavior as wget is given: you're taken to the homepage of the site after logging in.

Any solution?

After some more poking around, I think it might be possible to make this work by simply calling module_invoke_all("init") rather than doing a page reload and simply ensuring that securesite_init only runs once (perhaps through a static variable). If I have time, I'll give it a go.