I have a problem to run cron.php via wget. When i start command line wget LDAP SSO redirects me to user/login/sso and prevents anonymous access to cron.php

--2012-09-18 17:03:17--
Connecting to connected.
HTTP request sent, awaiting response... 302 Found
Location: [following]
--2012-09-18 17:03:18--
Reusing existing connection to
HTTP request sent, awaiting response... 401 Authorization Required
Authorization failed.

I need some option to disable LDAP SSO redirection for cron.php or other local URLs.

Members fund testing for the Drupal project. Drupal Association Learn more


geste’s picture

It seems like there have been a number of issue posts in the same vein, including this one about Maestro Orchestrator (a module we're also using) and SSO:


The "exception" case we ran into was that we have two Apache vHosts pointing to the same Drupal instance with LDAP and SSO enabled. While we want to have SSO for the vHost "private.example.com", we do not want it for the 2nd, anonymous, public vHost "public.example.com". Yet connections to public.example.com were redirecting to /user/login/sso.

I think we have fixed this for the time being by adding a few lines at the very top of the ldap_sso_boot function in ldap_sso.module:

$vhost = $_SERVER['SERVER_NAME'];
  if ($vhost == "public.example.com");

And this keep SSO from executing.

My sense is that John would agree that there's room for a more general exception facility in the SSO component that would handle exceptions for things like cron.php and also non-SSO pages and URLs. Being the perennial newbie, I am not sure of the cleanest way to implement that nor whether it should be opt-in or opt-out. My sens if that if SSO is enabled, exceptions should be of an opt-out nature like your example and mine.

johnbarclay’s picture

I think it should be configurable with the same syntax as block visibility, with the addition of a negation symbol. It also needs to allow hostname and root path, not just the drupal path. Some paths like cron should be in the list by default I would guess?


Does this seem correct?

truman_ru’s picture

@johnbarclay it would be good for me.

johnbarclay’s picture

Priority: Critical » Normal
7.23 KB

Here's a patch to get things going. I'm not using SSO so don't have a good way to test it. I feel its a bit of a hack since the drupal bootstrap doesn't have all the functions it needs. Some potential issues I haven't looked at:
-- will strongarm variables be loaded in hook_boot()?
-- will other modules that alter paths already be invoked in hook_boot()?

I haven't added the code for use cases where the hostname or http/https needs to be part of the "path" checking. That code would go in ldap_sso_path_excluded_from_sso() as well as the directions in the UI.

The related issues I see are:
#1369236: LDAP SSO: Add simpletest to make sure anonymous pages don't force sso authentication
#1379506: SSO: ldap_sso_boot() multiple issues
#1366420: LDAP SSO. Single Sign On Breaks Maestro Orchestrator
#1328750: LDAP SSO: drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL) is excessive

If this patch gets to the point where it meets some common use cases, I'll commit it. Ideally it would have a simpletest which should be easy to write #1369236: LDAP SSO: Add simpletest to make sure anonymous pages don't force sso authentication

arh1’s picture

I'm still trying to get my test environment set up so I can work on this, but in the meantime the patch in #4 didn't quite apply cleanly for me. The attached, tweaked patch does.

johnbarclay’s picture

Status: Active » Needs review

This is committed to 7.x-2.0-dev. Please test. See http://drupalcode.org/project/ldap.git/commitdiff/963a1bb88f2f38ac0a8905...

I also added more watchdog debugging for detail debugging since its hard to trace this code.

arh1’s picture

Attached is a patch that adds hostname-based exclusion. Interested to hear your thoughts, johnbarclay!

arh1’s picture

Oops, and shouldn't the path-based exclusion check the path against $_SERVER['PHP_SELF'] instead of $_SERVER['URL'] ? :) The attached patch addresses that, too.

johnbarclay’s picture

I like the patch and the idea. I wonder if a single textarea for both path, hostname, port, and protocal might keep the UI smaller and the functionality more flexible. I'm not sure the ideal syntax for the wildcards, if it should be apache mod rewrite style or, more likely, the drupal % approach.

Excluded Hostnames and Paths:

arh1’s picture

Just back from vacation... :)

I thought about combining the exclusion fields (hadn't considered port and protocol yet), but I wondered if it might be more expensive performance-wise (not to mention that the regex's are daunting :) ), and a more confusing UI.

For the UI, as an end user it seems it'd be simplest to specify protocols, hostnames, ports and paths in separate textareas.

That said, I'm inclined to add separate protocol and port fields to my patch above, but if you feel strongly I'll ditch that approach and start working on a combined textarea.

Looking forward to your thoughts!

johnbarclay’s picture

That sounds simplest and most usable. I would just do hostname and path to keep it simple. I think this is what you alreay have in comment #7. If you think its ready I'll commit it.

johnbarclay’s picture

I committed #8. Please test and when we feel good about it, we can mark it for simpletests.

arh1’s picture

Great! I pulled the latest 7.x-2.x changes and with some quick testing both path- and host-based exclusions seem to be working as advertised.

johnbarclay’s picture

Component: Code » SimpleTests

Great. I have the simpletests for ldap sso roughed out and will mark this for addition to simpletests so I can add it in when I get back to it. See http://drupalcode.org/project/ldap.git/blob/refs/heads/7.x-2.x:/ldap_aut...

geerlingguy’s picture

FYI, I've had nothing but good results using host exclusions as well. Does this issue still need to remain open?

johnbarclay’s picture

Component: SimpleTests » Code
Issue summary: View changes
Status: Needs review » Closed (fixed)
andreystrelkov’s picture

At the moment, what is the situation with this problem, I also try using CURL to launch cron and the response shows that it redirects to authorization via sso, and nothing