The redirect used by the single sign-on module breaks a number of important services, including RSS feeds (not all readers can handle redirects), sitemaps, Google site verification, and even Drupal's own cron.php service. I've put together a simple patch that fixes all of these. It's not the most elegant thing, but it does work.

Add this to the start of singlesignon_init():

  /* prevent redirections for special pages */
  $pagename = substr(strrchr($_SERVER['REQUEST_URI'], '/'), 1);
  if ($pagename == 'gsitemap' ||
      $pagename == 'feed' ||
      $pagename == 'rss.xml' ||
      $pagename == 'cron.php' ||
      $pagename == variable_get('gsitemap_verify','')) {
    return null;
  }

For the time being I am hosting a pre-patched module over on my site. If I hear of any other problem pages I will add them.

Thanks for the great module. I use it on my sites and other than these few special cases it works a treat.

CommentFileSizeAuthor
#7 singlesignon_allowbots_1.txt7.97 KBwayland76

Comments

Anonymous’s picture

Anonymous (not verified) commented

Thanks for this.

It actually also saves the problem of working with domain name that are not yet in the DNS. For example, setting the single signon master to mydomain.com and trying to access cron via IP would prevent cron from being ran.

starkos’s picture

starkos commented

I should mention that I discovered that this module also breaks indexing of your site (Google, Yahoo, MSN, etc.). I updated my patch to handle the worst of it, follow the link above to get the updated version.

starkos’s picture

starkos commented

I've made another update: the latest version of the sitemap module changed the sitemap file name from "gsitemap" to "sitemap.xml". My fixed module now reflects this change.

gaijinu’s picture

gaijinu commented

Hi starkos, thanks for your work, mate. But the link to your site doesn't work... Found a google cache but the tarball isn't there anymore.

Cheers.

starkos’s picture

starkos commented

Doh - sorry the URL alias changed, not sure why but I've fixed it.

I've also discovered found what looks like a stupid simple way to get single sign-on without using this module at all, take a look at this forum post.

karlrees’s picture

karlrees commented

I had to change the last condition. My gsitemap_verify variable is not set, so it was always causing the my front page to skip the singlesignon module. (The $pagename for the front page is equal to '').

So replace:

      $pagename == variable_get('gsitemap_verify','')) {

with this: 

      $pagename == variable_get('gsitemap_verify','gsitemap_verify')) {

Otherwise, thanks for this fix. It might be nice to have a place on the admin screen where you can specify additional pages or user clients to ignore, so I don't have to update my code every time I find one.

wayland76’s picture

wayland76 commented
Assigned: Unassigned » wayland76
StatusFileSize
new singlesignon_allowbots_1.txt7.97 KB

I've got a much more flexible fix. It's attached. Everyone please give it a go and see what you get.

wayland76’s picture

wayland76 commented

Oh, btw, the above fix is also committed to HEAD, and will no doubt roll itself out sometime within the next 24 hours or so.

The following are duplicates:
http://drupal.org/node/137042
http://drupal.org/node/170227

wayland76’s picture

wayland76 commented

Another duplicate: http://drupal.org/node/147445

wayland76’s picture

wayland76 commented

Another duplicate: http://drupal.org/node/112996

wayland76’s picture

wayland76 commented

Another duplicate (the oldest): http://drupal.org/node/97328

wayland76’s picture

wayland76 commented
Status: Needs review » Fixed

No complaints -- we'll call it fixed.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

danmuzyka’s picture

danmuzyka commented
Version: 5.x-1.x-dev » 5.x-1.3
Priority: Critical » Normal
Status: Closed (fixed) » Active

First of all, thanks for providing this module to the community.

Unfortunately, I have been running into some of the same problems that were supposed to be fixed in the update described in this thread.

I had to add some user agents to the default list. First, I edited the singlesignon_bot_matches array in lines 70-75 of singlesignon.module (version 5.x-1.3). I later realized that I had a syntax error in my code (I had 'target_url' => '/\/cron.php$|\/feed$|node_feed$|\/rss.xml$/' instead of 'target_url' => '/\/cron.php$|\/feed$|\/node_feed$|\/rss.xml$/').

Before I realized my error, however, I tried browsing to http://mydomain.com/admin/settings/singlesignon and adding to the list of permitted bots and to the list of Target URL referrers. After doing that, the bot and feed exclusions seem to work for a moment, but after a few minutes the settings revert to the default ones. In other words, if I browse back to the page http://mydomain.com/admin/settings/singlesignon a minute after adding to the list of bots and Target URLs, the new values are still present, but if I browse there or refresh after several minutes, the new values are no longer present.

Then I found my error in the singlesignon_bot_matches array in singlesignon.module, and after I added the correct values to the array, I found I could also add them from the admin form at http://mydomain.com/admin/settings/singlesignon and the settings persisted, even after a long duration of time had elapsed. For the time being I will continue to check the admin form to confirm that settings don't revert to defaults.

My question is, can you tell if this is a bug in the module or a problem caused by my coding? Is it necessary to add user agents and target URLs from both the module code and the admin form, or maybe the problem was my messy syntax interfering with the _singlesignon_get_bm_variable() function in the module? My PHP skills are still fairly novice-level, so I am not sure if there is a bug here, but if so I want to alert you to it. If not, thanks for looking into this anyway.

duaelfr’s picture

duaelfr
he/him
Primary language French
Location Montpellier, France
commented
Status: Active » 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.