Whew, this was a pile of bugs: 1.) The samplecontainer's application/javascript post was blocked by PHP shindig (Fixed: https://issues.apache.org/jira/browse/SHINDIG-1205)
2.) Even after fixing the content type issue, it looks like the samplecontainer service was never implemented in PHP (Request filed: https://issues.apache.org/jira/browse/SHINDIG-1207) but that still doesn't explain the OAuth error you saw. 3.) The toUrl() error is actually thrown when oauth.json is configured incorrectly. There's an error message attached to the exception, but it doesn't seem to get rendered anywhere (I needed to set a breakpoint and debug to read it). I used the following oauth.json code, which stopped the error: " http://gadgeteditor.appspot.com/spec/22001/demo-3-legged-oauth-to-partuza.nl.xml"; : { "partuza" : { "consumer_key" : "f9dbc6dc-e6fb-c8dd-87c1-dfdef8fff1de", "consumer_secret" : "b0c1a506e66ca67b5bbe5015de7b0523", "key_type" : "HMAC_SYMMETRIC" } } Where " http://gadgeteditor.appspot.com/spec/22001/demo-3-legged-oauth-to-partuza.nl.xml"; is the gadget I was running, "partuza" is the service name defined in my OAuth block: <OAuth> <Service name="partuza"> <Request url="http://www.partuza.nl/oauth/request_token"; param_location="uri-query" /> <Access url="http://www.partuza.nl/oauth/access_token"; param_location="uri-query" /> <Authorization url="http://www.partuza.nl/oauth/authorize"; /> </Service> </OAuth> And consumer_key and consumer_secret are the values given to me when I install " http://gadgeteditor.appspot.com/spec/22001/demo-3-legged-oauth-to-partuza.nl.xml"; on Partuza. 4.) Either Partuza has a bug which rejects oauth requests which use the Authorization header, or the oauth proxy code which generates the header is incorrect - I'm not sure, but all my requests to Partuza using the header were rejected for having an invalid signature (I needed to use Wireshark to find the response message). 5.) I guessed that maybe sending the oauth parameters via querystring would work, so I added param_location="uri-query" to the request and access definitions. Then the request sent the oauth parameters in the url, but they looked like they weren't encoded, and the request was still rejected. After some more debugging, I found that the OAuth proxy was decoding values it should have encoded (Fixed: https://issues.apache.org/jira/browse/SHINDIG-1206). Now the sample worked. So if you apply https://issues.apache.org/jira/browse/SHINDIG-1206 to your PHP Shindig, and use param_location="uri-query" in your OAuth service definition, and use the correct structure/values in oauth.json, you should get the sample to work. Admittedly, this is a mess, but since I'm in the middle of a patch to combine the 2 copies of the OAuth library in PHP shindig into 1, I'll try and get this code cleaned up and unit tested in the future. ~Arne
