Call to undefined function arg() on logout if page caching turned on

This problem has been bugging me too. Single Sign-On and caching just don't seem to get along very well. The undefined function arg is the result of singlesignon_init being called at a different stage during bootstrap as a result of caching being turned on. Normally singlesignon_init would be called during DRUPAL_BOOTSTRAP_FULL (see _drupal_bootstrap in includes/bootstrap.inc), but when caching is on it is called during DRUPAL_BOOTSTRAP_PAGE_CACHE, in drupal_page_header.

To fix the lack of arg(), you can add this in singlesignon_init:
drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH);

Unfortunately this doesn't solve all your problems. Different errors start occuring. One is that url() is still undefined, and to fix that you need to call drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);, but that will probably call singlesignon_init again, which we don't want, so maybe better would be to change this line:
singlesignon_goto($master_url . url('singlesignon/initial_check', $query));
to this:
singlesignon_goto($master_url . "/singlesignon/initial_check?$query");
But this is also not ideal.

After these fixes this error starts occuring at seemingly random times:
warning: Cannot modify header information - headers already sent by (output started at /.../includes/bootstrap.inc:543) in /.../includes/common.inc on line 139.

These errors might have something to do with drupal_page_header, and page_get_cache. When caching is enabled drupal returns different headers than it normally would, even for uncached pages.

Something that might contribute to some of these errors is the way singlesignon_goto works. It sends the browser to another site, and then back by using the Location header. But these are GET requests, so they are probably subject to being cached. Is there a way to make them POSTs? GETs are supposed to be idempotent, but we're dealing with state.

Anyway I think I can conclude that Single Sign-On just doesn't work with caching at the moment. For now I'm going to keep using the shared user tables on my sites, but disable Single Sign-On. That way users can sign up using the same username/password, but they have to log in/out manually on each site.

Calling the bootstrap functions is considered "safe." The bootstrap function has a static variable to see what has been called already, so it shouldn't call things twice.

I maintain the referertools.module. I had a similar problem with caching for splash pages. I had to call the bootstrap functions myself.

Do I like this? No, but it is a working solution.

I just made some commits in an attempt to resolve this. Can you please get the new version from CVS and let me know if that does the trick?

Thanks,

--Dan

the current cvs version gives me an access denied page from the login server site when I try to log in or out.

wrunt: Just making sure... you realize that there are three branches of singlesignon in CVS. One for DRUPAL-4-6, one for DRUPAL-4-7 and one for MAIN (which will become 4.8).

Which version of Drupal do you have installed? If it's 4.7, you need to get the copy from the DRUPAL-4-7 branch. If you're running cvs/MAIN, how recently have you updated your Drupal installation? Dries made some significant changes to how the admin menu system works for all of Drupal and I've implemented changes for that in MAIN.

The initial reporter had the version at 4.7.0, which wrunt changed to cvs. I'm changing it back to 4.7.0 because cvs isn't meant to be in complete working order.

I was using the cvs version with drupal 4.7.2, so I've switched to the 4.7 branch of singlesignon. I'm still getting access denied, but it may be because the sites I'm testing it on no longer share the roles table, since I wanted different roles on each site.

When trying to log in from example-b.com (the slave site) I get an access denied page on example-a.com, at the url:
http://example-a.com/singlesignon/login?slave_session=43c3645877b8b2678f...

wrunt:

what happens if you change the constant used in line 92 from "DRUPAL_BOOTSTRAP_PATH" to "DRUPAL_BOOTSTRAP_FULL"?

If that doesn't fly, what about putting the following on the first line inside singlesignon_init():
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

If you're still having issues. Log into example-a.com and make sure the singlesignon module is enabled and has it's the master url set to "http://example-a.com".

Ah, I had forgotten that the master site had to have its master url set to itself. Maybe this should be the default?

It works now. Thanks for your hard work danielc, this is a really cool module :)

wrunt suggests:

> I had forgotten that the master site had to have its master url
> set to itself. Maybe this should be the default?

That can't be done because there's no way for the module to know which site the owner intends to be the master.

> > I had forgotten that the master site had to have its master url
> > set to itself. Maybe this should be the default?

> That can't be done because there's no way for the module to know which site the owner intends to be the master.

But couldn't each site start out as its own master, and then be changed to the real master later?