Everything works fine on my localhost.
But on a live server, I don't get the imagefield files when I run a content retrieval.
It's definitely not a permissions thing, because I can do this in the Exec PHP block and it works perfectly:
$file = content_retriever_xmlrpc('file.get', 110); // whichever fid is on the remote node
dsm($file); // WORKS!
So the question is -- how can the exact same line of code work when given in the PHP block, but not as part of an update?
Remembering the blog post about the clock (http://www.drupaler.co.uk/blog/drupal-services-and-dreaded-clock/466) I tried increasing the Token expiry time. You'd think 30000 would be okay no? Nope.
I tried the debug patch to the Key auth module () and my Drupal log I got an 'Access denied'. The only place in the code that an 'Access denied' message is given is this:
if (!db_result(db_query("SELECT COUNT(*) FROM {services_key_permissions} WHERE kid = '%s' AND method = '%s'", $api_key, $method_name))) { return services_error(t('Access denied.'), 401); }
Surely if that fails as part of an update, it should ALWAYS fail, even when done manually. It's the same user account, the same API key, etc.
What DOES solve the problem is commenting out the part in content_retriever_xmlrpc() that checks $login_session_id -- in other words, if we make content_retriever_xmlrpc() do system.connect and user.login before EVERY method call, it works. But I still don't see how that can be giving a services_key_permissions error!
Does anyone have any ideas?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 711542.content_distribution.added-skip-login-setting-quick-fix.patch | 3.01 KB | joachim |
Comments
Comment #1
joachim commentedSo just to summarize what we know:
- running the file.get method in the PHP block is fine. So it's not perms on the remote server.
- forcing a login on each method call is fine.
- chaining all calls after one login fails.
- chaining all calls after one login *on a localhost* is fine.
The only difference I can see is that on a localhost, everything runs quicker. So it has to be a timeout problem of some sort. And yet the error messages say something else....
*sigh*
As a workaround, I am going to add a setting to force a login each time, and enable it by default. Kludgy :(
Comment #2
damienmckennaAre your session cookies getting dropped on the subsequent http request?
Comment #3
joachim commented#711542 by joachim: Added setting to not skip login.
This is a quick fix. Leaving this open.