When I transitioned a multisite setup from the deprecated Shared Sign-on module to sso, I was dismayed to find out that same-domain multisite is not supported. This is a regression. I have three sites as follows:

  • example.com (site 1)
  • example.com/site2
  • example.com/site3

...with all tables in the same MySQL database. The following tables are shared, being named with a "shared_" prefix: authmap, profile_fields, profile_values, role, sessions, users, users_roles. The remaining tables are prefixed with "site1_", "site2_" or "site3_" respectively. Domain Access is not used. This configuration worked under the older module.

With the new sso controller module enabled on Site 1, and the sso client module enabled on Site 2 and Site 3, the message "Only one single sign-on module can be installed at a time. Please disable single sign-on client or controller on this site" showed on Site 2 and Site 3.

The attached patch restores same-domain multisite support. It makes the following changes:

  • $base_url, not the current domain, is checked against the variable singlesignon_client_controller_url in singlesignon_ignore_request().
  • The request_data passed with the "associate" request is altered:
    • 'origin' now contains the $base_url of the client site.
    • 'redirect' contains the path on the client site from which SSO login was attempted.
  • The request_data passed with the "claim" request is altered. 'origin' is no longer passed. 'redirect' is passed.
  • Some uses of url() are changed make use of optional features described in the API documentation.

Currently the redirect on the client site after login does not happen; however, there is no error. I would appreciate some advice on updating the patch so this feature works.

Comments

meba’s picture

I don't think this is going to work. But you can try :-)

First, make sure that if you fiddle with origin/redirect variables, check that hmac is also signing these variables.

Second, the redirect happens in controller form submit function, this is what you didn't change.

Paul Natsuo Kishimoto’s picture

Thanks for the tips, I'll take another look.

Can you be more explicit about why it might not work?

Paul Natsuo Kishimoto’s picture

Status: Needs work » Needs review
StatusFileSize
new5.08 KB

Here's another patch. Thanks to #1, I was able to fix the redirection. I also changed the name 'redirect' to 'destination' to match core.

HMAC signing wasn't an issue. The patch simply sets new variables or request data, or sets the existing ones differently—but it does so in the same locations, i.e. before signing occurs.

I know this is not the old singlesignon module, which was deprecated for being insecure. Still, security-conscious users with single-domain multisite who move to sso (as instructed) will experience this as a regression, as I have said. I hope someone can test it on a multi-domain configuration and confirm that it doesn't disrupt behaviour.

vladsavitsky’s picture

StatusFileSize
new5.02 KB

I want to suggest a patch modification.
Simple change 'destination' to 'dest'.
Drupal uses this word to redirect to original page and some modules too.
For example, logintogobban module not work with previous version of patch but works correctly with current.

Thanks for patch and for SSO-module.

dave_robinson’s picture

The singlesignon_ignore_request function will need a global $base_url added for this to work.

You'll probably want to add a call to singlesignon_ignore_request to singlesignon_client_form_alter so that you can skip the form alter in this case. Otherwise a login directly to the master will rediect you to user/login.

nathan.zhu’s picture

sorry, i use sso module let it working with multi-drupal, but it doesn't works for me. I make the patch for sso module but still not working.
always get page not found on subsite, do you have same problem with me? please help, thanks.
i create the site below:
drupal.local.com
ndrupal.local.com
follow the correct sso documentation.

get page not found when i setting single-sign-on-client on subsite.
the url is :http://ndrupal.local.com/singlesignon/claim?nonce=e8969b86f0071372&dest=...

nathan.zhu’s picture

strange problem, disable the single-sign-on-client on subsite and $conf['session_inc'] = 'sites/all/modules/contrib/sso/session.singlesignon.inc' on settings.php file, it works for sharing user login..... why, ?????? any body can help?

netsensei’s picture

Need this functionality too.

I integrated the patch with the latest version of single signon. A few remarks:

1.

You might want to patch against the CVS version of the module. The patch botched here so I had to execute the changes manually. It's not a big module, but it meant manual labour nonetheless.

2.

This is my set up:

http://site.lan/ = client
http://site.lan/site2 = controller

* I had to disable the form_set_error: 'The controller URL must be at the root of a domain.' To enter the controller url
* If I log in on the client, I get redirected to the controller and not back to the client. I'm logged in on both sites though.
* If I start an erroneous login, the form on the controller site is displayed rather then on the client site. Which is quite confusing if you are a regular user.

netsensei’s picture

If I log in on the client, I get redirected to the controller and not back to the client. I'm logged in on both sites though.

I stand corrected: I had the Login Destination module enabled on the controller site. This module took over after login.

Paul Natsuo Kishimoto’s picture

@netsensei: if you had to reroll the patch, please post your version.

I would also appreciate if you could e-mail the maintainer (meba) and ask him to commit this patch (or a version of it) and actually put out a 1.0 release. There have been no releases of sso since singlesignon was blacklisted on the same day that sso 6.x-1.0-rc1 was released.

sachbearbeiter’s picture

subscribe

Albrecht Marignoni’s picture

ndm’s picture

the patch #4 cannot be apply normally with the standard version. you must apply on the parent directory

So for me this work

abhishek sawant’s picture

will i be possible to work with sub-directories like http://example.com/data and http://example.com/data2 as 1st url as controller and 2nd url as client?

ndm’s picture

Status: Needs review » Reviewed & tested by the community

Yes it's works with a configuration like yours

shushu’s picture

I would like to ask whether this patch can work in my case, and what exactly I should do to set it up.

- I am working with Open Atrium.
- I am using Persistent URL to create domain-per-group (not subdomain), so group1 gets group1.com, group2 gets group2.com, and the main site is mysite.com.
- The whole site is the same - same code, same content, same tables. The whole difference is done by Spaces and the rest of Open Atrium "magic".

I tried to install the SSO, and of course got the message "Only one single sign-on module can be installed at a time".
Setting up the $cookie_domain in several ways does not solve anything either.

Is this configuration can be solved by this patch ?
If so, does it mean all I need to do is to install the controller and setup the settings.php with the session_inc ?

Regards,
Shushu

tonirv’s picture

@nathan.zhu:
Same problem here.
I have an scenario of DA + SSO running smooothly on a shared hosting company platform. Im moving to another hosting company and get myself pissed off when I find that SSO don´t work at all.

I tried to setup from the scratch two domains and I didn´t managed to make it work.
I tried to change clean urls, but didn´t work

I don´t know if the .htaccess option +FollowSymLinks is needed to keep SSO working, cause my company has disabled this option, raising a 500 HTTP error code if it´s present in our .htaccess files.

Any ideas?

tonirv’s picture

FYI, my issue was solved.

My hosting company support service detected that modsec was blocking the sso redirection.
All those who were receiving "Page Not Found" with the sso controller url adress, check the modsecurity status for that domain.