I'm confused about using the Services browser when api keys are enabled...
Environment:
Drupal 6.16 (actually Pressflow distribution, but still normal Drupal)
Services 6.x-2.0
Installations:
1) (temp while developing) a shared linux server at GoDaddy
2) a shared Linux server at HostGator running Drupal with an Ubercart setup selling custom digital products
3) an XServe at a coLocation running Drupal and proprietary OS X only software
for the moment, installation 1 is mimicking the behavior of installation 3, where the final behavior of the setup is:
a) consumer purchases a custom digital product from the store at installation 2
b) via services.module, the details of the custom product are sent to the XServe at the coLocation
c) XServe receives the custom product info via it's own services.module
d) XServe creates custom product
e) XServe uses services.module to send the custom product back to the online store at HostGator.
In order to get this working and secure, I have api keys enabled for both web sites.
When I'm doing simple tests, I have a service callback function "test" that opens up an xmlrpc connection to send information to the "other" installation (if logged into the store, then the other installation is the XServe; if logged into the XServe, then the other installation is the online store.)
Using the Services browser to execute this "test" function, if I do not have api keys enabled everything works normally, as in the parameters are all what I expect. However, if api keys are enabled, then the "test" routine receives an additional 1st parameter (I don't know what it is) and my expected parameter is next.
Now, I have an api key that I named "loopback" with the same domain as the web site, for use in local uses of the Services browser. This is in addition to another api key for the "other" web site to talk to this web site.
Whenever I use the Services browser to call this "test" routine, I get a red "trigger _error" box telling me "Authentication failed: Access denied.", yet the routine "test" gets called and my communication with the "other" web site is successful. What is getting denied?
I hope this is a clear descrption. In summary, my questions are:
1) what is that additional parameter being passed by the Services browser when api keys are enabled?
2) what is being denied when my routine is being called fine?
My xmlrpc logic is based upon this: http://groups.drupal.org/node/57483 (a post from this very group!)
FWIW, the xmlrpc logic works great, and I'm sure the authentication failure is not being caused by the xmlrpc logic. I'd modified all it's error message so I'd recognize them...
Comments
Having the exact same
Having the exact same problems. Somehow I alway's get the Access Denied through the browser. It makes it a bit more difficult to debug... I would love to see an solution to this one.
Domain name issue?
I'm not sure if this is related, but I've been tricked before with the wrong domain name argument when using the services browser.
When creating an API key, you typically use the production domain name as the value of this argument (although really it can be any value). If you're working on a development or staging drupal install with a different domain name (or even a sub domain of the form sub.example.com), the services browser automatically fills in the value for the domain name argument as the current domain name, which is will not work (give "Access denied" error) because the API key was created with the production domain name.
For example, suppose your production site is abc.com and you have a test sub-domain test.abc.com. If you created the api key with domain name of "abc.com", when you go to the services browser on test.abc.com, you'll see that the domain name argument is by default filled in as test.abc.com and if you call the method that way you'll get an access denied. Just change the domain name argument to abc.com and it will work (assuming this is the issue ...).
HTH.
Micah