I often get "page not found"

In includes/common.inc on all your slave sites (and doing so in the master site doesn't seem to hurt, either), try changing lines 1184 through 1190 to be the following (after applying the multisite_alias.patch patch):

if (strpos($path, '://') !== FALSE) {
$base = '';
} else if (in_array($path, array("singlesignon/initial_check", "singlesignon/login"))) {
$base = '/';
} else {
$path = drupal_urlencode($path);
}

My slave site is formatted as follows:

http://www.slavesite.com/admin/path/to/slave/singlesignon/

and the master site is

http://www.mastersite.com/admin/singlesignon/

and this module was originally appending /path/to/slave onto the master site's URL, producing

http://www.mastersite.com/admin/path/to/slave/singlesignon/

This hack seems to patch things up, though I haven't tested it adequately for it to be called an official patch. If anyone has any problems with this, please take a second and post, cause I'm relying on this too!

Whoops! Didn't mean to change the title of this issue. Changed it back.

I closed the duplicate at http://drupal.org/node/165247

Have you tested the patch that is included inside the multidomain module?

http://drupal.org/project/multidomain

Closed duplicate: http://drupal.org/node/129455

...and just to reiterate, please test with the latest version, too.

Hi,

I just checked it with 5.x-1.2 and I get Page Not Found!

After downgrading to 5.x-1.1, the Page Not Found error is gone, after deleting all my cookies.

Regards,

Tobi

Adding these paths to Domain Access' Special page requests setting fixes this issue, too:

singlesignon/login
singlesignon/initial_check

I think that either Domain Access or Shared Sign-on should add these paths automatically to the default configuration upon installation.

Anyway, it should be mentioned in SSO's documentation at least.

You can use hook_enable() to alter the default settings of the Domain module when turning on SSO.

See http://therickards.com/api/function/mysite_enable/MySite for example.

This could also be done, less efficiently, in hook_domaininstall().

http://therickards.com/api/function/hook_domaininstall/Domain

Now, let's make this critical. Attached patch, in combination with #256007: Single Sign-on and SEO, fixes a very simple oversight in SSO, justifying a 5.x-1.3 release.

Not visible in the patch:

/**
 * Sets up the URL and goes to it
 */
function _singlesignon_goto_url($url) {
      // url() only available if bootstrap has reached FULL.
      drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);

      $query = 'slave_session='. session_id() .'&singlesignon_dest='. _singlesignon_get_dest();
      _singlesignon_goto($master_url . url($url, $query));
}

I don't have much time to dedicate to this until Saturday at the earliest, and maybe Monday.

@agentrickard: I'll check out the information you provided when I have the time

@sun: Ok, I'm confused. The first thing is, I don't see any patch attached. I presume you mean one of the code blocks attached to one of the comments; if so, which comment are you referring to? If you're referring to comment #10, then I can't immediately see how this differs from what's in CVS (which I think is the same as the release). If you're referring to comment #1, then that code doesn't change SSO, but Drupal Core.

Strange. I could have sworn that there was one when I posted.

Long story short: $master_url is not defined in _singlesignon_goto_url(), but it's required - hence, users are not redirected to the correct site on multi-sites using completely different domain names.

I think I could've stared at the code for quite a while before seeing that :). Thanks.

If that's all the time required, I can do that right now. Let's declare victory on this one, and hope that the other one resolves any remaining problems.

Thanks. I've done some additional testing now and it seems that adding singlesignon/* to Domain's special page request paths might not be needed anymore.

However, the patch in #256007: Single Sign-on and SEO (Domain) is still required.

Ok. Hopefully agentrickard will take some appropriate action; he's usually been pretty good in my experience.

I don't know enough at this point. The domain system only rewrites node link paths, so I fail to see how these changes have any effect.

I will track that over at http://drupal.org/node/256007