"The server script is not accessible. Please modify your server configuration, so that the script /sites/all/modules/udc/server/server.php is callable via HTTP/HTTPS."

I have the server script in this location and it is still saying it is not accessible. I have changed the permissions of the scripts and nothing works. Any ideas what may be going on here? I am not using HTTPS. I would really love to use this module. The examples all fail as well. I have used the token generated but to no avail.

Comments

stfwi’s picture

Hi, let's trace this from possibility to possibility. My guess is that either the .htaccess in the root, or below, or the apache conf does either not allow to run scripts not in the web root, or redirects it implicitly to /index.php. Can you please do the following steps:

  1. The module needs to be in DRUPAL_ROOT/sites/all/modules/udc, not in DRUPAL_ROOT/modules
  2. File permissions of server.php should be 644 or the like (no exec bit, no write bit for users other than the owner)
  3. Try to access the script in the browser: e.g. http://localhost/server/server.php. Normally you should get a response like this:


    {"status":false,"data":[],"processtime":0.034,"error":"No request"}
    

    If return code is 401 && the message exactly this:

    <h1>Not Authorized</h1>

    ... then IP address validation very likely failed, means the server script is accessible but refuses to answer. If this is not the case, the execution of the script is blocked. You can additionally comment out the line 116 "kill_connection()" in server.php to disable the IP check.

  4. Check the .htaccess in the Drupal root directory, DP has for good reasons quite good security settings and normally denies or redirects scripts somewhere in the sub-tree. [edited: I saw after submitting the form that I did not see one dot in the regex, so the lines that I specified here are not the important ones : )]. But please check the file contains restriction statements.
  5. Can you give me some additional info if you are using Linux or Windows; localhost or directly on the server etc, it could help as well.

Cheers

Stefan

stfwi’s picture

I have an additional check worth to test. In file ./sites/all/modules/udc/client/DrupalUserBase.php line 193 is the path assembly:

$path = dirname(dirname(str_replace($_SERVER['DOCUMENT_ROOT'], '', __FILE__))) . '/server/server.php';

Can you temporarily insert the lines

print $path;
exit();

after this and call the ping example in the browser, e,g: http://localhost/sites/all/modules/udc/examples/ping.php. The response should be the correct path to your server script, in my case: /sites/all/modules/udc/server/server.php. If this is not the case, I need to fix this in the code. (If you could provide the path in your case - would be perfect).

Cheers

Stefan

stfwi’s picture

Assigned: Unassigned » stfwi
Status: Active » Needs review

I analysed the code yesterday and saw a potentially faulty url path detection for windows or the case that links are used, so that the url of the server script cannot be determined from the server document root and known library path. So the absolute url path (without the server name) can be specified now using the macro USER_DATA_CONNECTOR_MODULE_PATH in this case. Means: if you define ...

define("USER_DATA_CONNECTOR_MODULE_PATH",  "/<url prefix for drupal>/sites/all/modules/udc/");

... then the client API will try to access the server script using ...

http[s]://[localhost or server name]/<url prefix of drupal>/sites/all/modules/udc/server/server.php

The change is contained in the commit: http://drupalcode.org/project/udc.git/commit/16ee2d9

stfwi’s picture

For the record: I think I found and fixed an issue for the case that the server is behind a router or the like, so that the IP addresses (of request and internal server definition, e.g. WAN and LAN) don't match up. The fix is contained in 7.x-1.x-rc2.

Note according to the example scripts: They only work if the request comes form localhost. You need to modify sites/all/modules/udc/example/enable_examples.inc and comment out the if($_SERVER['SERVER_NAME'] != 'localhost') { ... } clause if you want to enable them on a public server (which is not recommended).

Let me know if it helped.

stfwi’s picture

Status: Needs review » Fixed

The same problem occurred on the platform of another user. After using the DEV snapshot the problem was solved.

stfwi’s picture

Status: Fixed » Closed (fixed)