Posted by greg.harvey on December 11, 2009 at 4:09pm
Jump to:
| Project: | Services |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi,
I was testing an xmlrpc web service locally, hitting it with a script running on localhost, no problem. I migrated it to a machine on the 'net and it stopped working. To be clear:
1. Keys are enabled
2. The correct methods are enabled against the key
3. The script accessing the web service is definitely ok, because it works locally
4. The domain for the key is correct
Basically, system.connect works ok but every service after that says "Access Denied". Even from the admin screen. Same database, same set-up, same script all works fine locally. Any suggestions?
Comments
#1
Ok, this is switching to support request - because I deployed the same app to my CentOS test server and it worked fine. So it seems there is an issue specifically on the Ubuntu Server production box. It belongs to a client and I have no other Ubuntu hardware to play with right now. Anything Ubuntu needs to have installed? I shouldn't have thought so. This is most odd! =/
#2
Another quick update - admin form consistently fails everywhere. =(
But there's probably other issues dedicated to that...
#3
So the first thing I would look into is what version of PHP is running, that's the biggest red flag for issues like this. Ideally it should be 5.2 or higher (although D6 officially supports 4.3.5 it is possible that Services has some 5.x-specific code in it.)
Another possibility is that their PHP installation doesn't have some common component.
So my first line of attack would be to check phpinfo() on both sites and compare them. Check the PHP versions and then check to see if there are any plugins that the working one has which the broken one doesn't. Get back to me with your findings, this could be good stuff to add to the handbook.
#4
Hi,
Thanks for coming back so quick. So, it's PHP 5.2.11 on Ubuntu - PHP 5.2.6 on the CentOS box and on my local Fedora machine.
The error was masked by this bug: #657444: xmlrpc_server can't handle some error responses
But once I got the error object in to watchdog, I could see it was actually
Token has expired.Token generating PHP looks like this, and works fine everywhere else I use it with the Drupal Services module:
<?php
/**
* Function for generating a random string, used for
* generating a token for the XML-RPC session
*/
function getUniqueCode($length = "") {
$code = md5(uniqid(rand(), true));
if ($length != "") return substr($code, 0, $length);
else return $code;
}
// set vars for this connection
$nonce = getUniqueCode("10");
$method_name = 'user.login';
$timestamp = (string) strtotime("now");
$required_args = array();
// now prepare a hash
$hash_parameters = array(
$timestamp,
$domain,
$nonce,
$method_name,
);
$hash = hash_hmac("sha256", implode(';', $hash_parameters), $kid);
// prepared the arguments for this service
$required_args = array(
$hash,
$domain,
$timestamp,
$nonce,
$response['sessid'],
);
?>
So could PHP 5.2.11 cause issues with Services' ability to decipher tokens? Like I say, PHP 5.2.6 on CentOS, no worries. =/
#5
By any chance are the servers in different timezones?
#6
Ahhhh, yes!!! LOL. Let me try that out.
#7
That's something we should figure out how to address if it is in fact the issue. You could adjust the line
$timestamp = (string) strtotime("now");to use the adjusted time to match the server's timezone?
#8
Yup, timezone it was. Thank you so much! It's always the silly little things that catch me out. =)
For reference, adjusted line was:
$timestamp = (string) strtotime("+1 hour");#9
I got burned by that when writing Deploy too.
#10
Actually, you know what? I set the time back to "now" out of curiosity and it still works. But while I was at it, I remember the server clock was wrong and updated it. So actually, it was an incorrect server clock that was killing me, not timezones. But you put me on to it. Would *expect* timezones to potentially cause issues, but it seems timestamps work regardless of server timezone - guess they're all GMT.
#11
Automatically closed -- issue fixed for 2 weeks with no activity.