Cannot connect to Drupal...

[MichaelAstech]

I have been struggling to configure the Drupal Services module in Moodle for several days now. I am using

• Moodle 2.6
• Drupal Services plugin from the 2.x-2.x-dev branch (downloaded 19/12/2014)
• Drupal 7

Both Moodle and Drupal are installed on my localhost, and I have set up a domain locally on my computer, i.e. they are located at:

• sso_test.com/moodle_sso
• sso_test.com/drupal_sso

I have followed the configuration instructions for both Drupal and Moodle as outlined at:

https://github.com/cannod/moodle-drupalservices/wiki

In the Drupal Services configuration page, I have set the Drupal Website URL to:

http://sso_test.com/drupal_sso

Nevertheless, I am experiencing problems connecting to the Drupal installation. Users who are defined in the Drupal database cannot log into Moodle.

With Moodle debugging turned on, I see the following information at the top of the Drupal Services configuration screen:

Using preconfigured values: stdClass Object ( [call_logout_service] => 0 [cohorts] => 0 [cohort_view] => [field_map_address] => 0 [field_map_city] => 0 [field_map_country] => 0 [field_map_department] => 0 [field_map_description] => 0 [field_map_email] => 0 [field_map_firstname] => 0 [field_map_idnumber] => 0 [field_map_institution] => 0 [field_map_lang] => 0 [field_map_lastname] => 0 [field_map_phone1] => 0 [field_map_phone2] => [field_map_url] => 0 [host_uri] => http://sso_test.com/drupal_sso [remote_pw] => moodle-user [remote_user] => moodle-user [version] => 2014111400 )

line 79 of \auth\drupalservices\settings.php: call to debugging()
line 85 of \lib\classes\plugininfo\auth.php: call to include()
line 95 of \admin\settings\plugins.php: call to core\plugininfo\auth->load_settings()
line 6412 of \lib\adminlib.php: call to require()
line 19 of \admin\settings.php: call to admin_get_root()

attempting to reach service url: http://sso_test.com/drupal_sso/moodlesso/moodlesso

line 183 of \auth\drupalservices\REST-API.php: call to debugging()
line 296 of \auth\drupalservices\REST-API.php: call to RemoteAPI->CurlHttpRequest()
line 106 of \auth\drupalservices\settings.php: call to RemoteAPI->Settings()
line 85 of \lib\classes\plugininfo\auth.php: call to include()
line 95 of \admin\settings\plugins.php: call to core\plugininfo\auth->load_settings()
line 6412 of \lib\adminlib.php: call to require()
line 19 of \admin\settings.php: call to admin_get_root()

Reached out for the cookie form the server and got: stdClass Object ( [cookie_domain] => .sso_test.com [role] => Array ( ) )

line 107 of \auth\drupalservices\settings.php: call to debugging()
line 85 of \lib\classes\plugininfo\auth.php: call to include()
line 95 of \admin\settings\plugins.php: call to core\plugininfo\auth->load_settings()
line 6412 of \lib\adminlib.php: call to require()
line 19 of \admin\settings.php: call to admin_get_root()

(A screenshot of the Configure Drupal Services page is attached)

Can you advise me on what I am doing incorrectly?

[netw3rker]

You are almost there, the old 1.x version of the plugin required the endpoint name, but now you don't need it. Just give the website address of the Drupal site, and it will do all the rest. Currently you have it set to: "http://sso_test.com/drupal_sso" and it should just be http://sso_test.com

This is because the moodle_sso module in Drupal provides its own service endpoint that the moodle plugin explicitly checks for.

[MichaelAstech]

Thanks, I'll give that a try...

[netw3rker]

Cool, also try the latest updates from the 2.x-2.x-dev branch. Another person had a similar issue and we found and fixed a couple of bugs.

[netw3rker]

Hi @MichaelAstech , I know it's the holiday season, but any word on whether this helped?

Thanks!

[MichaelAstech]

Hi, Sorry, I haven't had much opportunity to look at it, but I'm now getting a different error:

Using preconfigured values: stdClass Object ( [call_logout_service] => 0 [cohorts] => 0 [cohort_view] => [field_map_address] => [field_map_city] => [field_map_country] => [field_map_department] => [field_map_description] => [field_map_email] => [field_map_firstname] => [field_map_idnumber] => [field_map_institution] => [field_map_lang] => [field_map_lastname] => [field_map_phone1] => [field_map_phone2] => [field_map_url] => [host_uri] => http://sso_test.com [remote_pw] => moodle-user [remote_user] => moodle-user [version] => 2014111400 )

line 79 of \auth\drupalservices\settings.php: call to debugging()
line 85 of \lib\classes\plugininfo\auth.php: call to include()
line 95 of \admin\settings\plugins.php: call to core\plugininfo\auth->load_settings()
line 6412 of \lib\adminlib.php: call to require()
line 19 of \admin\settings.php: call to admin_get_root()

attempting to reach service url: http://sso_test.com/moodlesso/moodlesso

line 183 of \auth\drupalservices\REST-API.php: call to debugging()
line 296 of \auth\drupalservices\REST-API.php: call to RemoteAPI->CurlHttpRequest()
line 106 of \auth\drupalservices\settings.php: call to RemoteAPI->Settings()
line 85 of \lib\classes\plugininfo\auth.php: call to include()
line 95 of \admin\settings\plugins.php: call to core\plugininfo\auth->load_settings()
line 6412 of \lib\adminlib.php: call to require()
line 19 of \admin\settings.php: call to admin_get_root()

The moodlesso service is unreachable. Please verify that you have the Mooodle SSO drupal module installed and enabled: http://drupal.org/project/moodle_sso

line 121 of \auth\drupalservices\settings.php: call to debugging()
line 85 of \lib\classes\plugininfo\auth.php: call to include()
line 95 of \admin\settings\plugins.php: call to core\plugininfo\auth->load_settings()
line 6412 of \lib\adminlib.php: call to require()
line 19 of \admin\settings.php: call to admin_get_root()

Do I need to update the Drupal plugin as well as the Moodle one? Moodle now appears to be looking unsuccessfully for:

http://sso_test.com/moodlesso/moodlesso

The endpoint http://sso_test.com/moodlesso/moodlesso does not exist, but (I have checked in my browser), the endpoint

http://sso_test.com/drupal_sso/moodlesso

does exist. It seems to me that the drupalservices plugin is looking for an incorrect endpoint name, but I cannot figure out why it is doing so. (I have purged the moodle cache...)

[MichaelAstech]

I finally figured out that my problem was that I had configured my Drupal site incorrectly - I had both Moodle and drupal in subdirectories, viz.:

sso_test.com/drupal_sso sso_test.com/moodle_sso

When I changed my configuration so that drupal was reached at sso_test.com, the drupalservices plugin was able to find the endpoint successfully.

I did find that it was necessary to reinstall the drupalservices plugin a few times. As currently designed, if the configuration is ever partly configured but the cookiedomain is not properly set, then the cookiedomain can never be set again. This can be seen in line 112 of settings.php

if($config->cookiedomain == '' && $configempty){

A partial setting of the configuration will result in $config->cookiedomain being equal to an empty string, but with $configempty equal to false. The result is that the code setting the cookiedomain to the value retrieved from the moodlesso service will never be executed. I'm not sure whether this is a bug or an undocumented feature ;-)

[netw3rker]

Hah! nice work :)

I swear I checked 2x for that double subdirectory situation and totally missed it both times. I've been hoping someone would come out of the woodworks with an example.com/drupal and example.com/moodle configuration since it is both the edge case I didn't expect anyone to have, and is really the only one the code can't automatically detect.

One step you might have missed in this is that the $cookie_domain value in Drupal's settings.php file needs to be ".sso_test.com". If you don't do that, and have Drupal running as a sub directory, the cookie domain will be "sso_test.com/drupal_sso" which will be inaccessible to sso_test.com/moodle_sso.

You are right about the cookie issue breaking the ability to reconfigure the system, and that needs to be resolved. Thanks to another user, we at least put some code in that at least adapts to that problem pretty well, but wouldn't have caught your situation. If you intend to keep your structure this way, I'd like to set up a feature branch to try to accommodate that situation. I think the first fix would (obviously) be to add a field to edit the cookie domain. I think checking to see if the base-url in moodle exists within the drupal service url, would allow for some better configuration tests to detect the specific problem you have.

[MichaelAstech]

First of all, thanks very much for your help with this! For the moment I resolved the situation by adjusting things so that my drupal installation is reached at sso_test.com and my moodle one at sso_test.com/moodle. This is really just a temporary fix, though, as ideally we'd like to have a sort of home landing page at sso_test.com which would provide links to the CMS and LMS applications, as well as to some other applications which we develop ourselves. The idea is to provide customers with an integrated experience. I presume that a configuration using subdomains ( drupal.sso_test.com and moodle.sso_test.com) would meet our requirement...

[netw3rker]

Yep, lets get to the bottom of this. Can you try setting it back to sso_test.com/drupal_sso and sso_test.com/moodle_sso then set the $cookie_domain to .sso_test.com in your settings.php file?

I'd like to know if the issue for you has been around cookie assignment the whole time, or something else. I'm specifically interested in whether you can get it to resolve the cookie correctly with a url that has subdirectories. I think that the auto detection isn't checking for the possibility of a cookie that doesn't match the url path, and that's a missing component of this.

[MichaelAstech]

I'm pretty sure I tried that particular combination without success. I don't have the resulting output to hand though - I don't recall the debugging logs being any different, although I may have suffering from a sort of snow-blindness by that stage!

[netw3rker]

I hear ya, I'm dealing with a weird infinite redirect problem right now & am pretty much flying blind trying to solve it at the moment ;) anyhow, I'd like to design some code around this to fix it, so if you get a test env running with that specific configuration, lets try to knock this out.