There is a slight flaw with the way the module detects whether the current site is the master. In some circumstances the master domain may be available on both HTTP and HTTPS (for example when using the securepages module), with some pages on each. The session in this scenario is still shared between the two schemes, but singlesignon thinks the domain on the other scheme is a slave site.

I've rolled a patch that changes the master checks to strip off the scheme when determining whether it's on the master domain. This has fixed my setup.

Just to give more detail on my problem, I've used hook_form_alter() to change the action of my user login form to the HTTPS version of the same page, even though the page it's submitting from is on vanilla HTTP. The problem is that on first login, singlesignon catches the POST request on what it considers a new site (the HTTPS version of the same one, actually) and redirects back to master, before Drupal has had a chance to actually process the login form.

It might be a good idea to prevent redirects from hook_init() occurring on a POST request as well, but I'll leave that up to you...

While this is a bit of a corner case bug, I can't see how my fix would break anything else.

Thanks!

CommentFileSizeAuthor
singlesignon.module.patch1.86 KBneilnz

Comments

duaelfr’s picture

Status: Needs review » Closed (won't fix)

This version of Shared Sign-On is not supported anymore. The issue is closed for this reason.
Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

This issue has been automagically closed by a script.