The content type can (and should) be specified in the request headers.
You probably want something like this:
gadgets.io.makeRequest("localhost:7070/social/api", callback, {
METHOD: "POST",
AUTHORIZATION: "OAUTH",
CONTENT_TYPE: "JSON", // This refers to the expected result type
POST_DATA: gadgets.io.encodeValues(jsonRpcRequest),
HEADERS: { "Content-Type", "text/json"}
});
On Fri, Apr 17, 2009 at 8:28 PM, Mark D Weitzel <[email protected]> wrote:
> Quick question regarding the recent work with Shindig's OAuth support.
> Here's the scenario: I've got two instances of Shindig running, one on
> port 7070 the other on 8080. What I'd like to be able to do is a
> makeRequest(restURL) from a gadget on 8080 to 7070. This would cause the
> OAuth to kick in and I should see the oauthpopup and the login screen from
> the second shindig. The goal is to easily see the "end-to-end" behavior of
> what shindig does for OAuth. For convenience, I'm just hitting the social
> api on the second (7070) shindig.
>
> So all was working great until.... I loaded the latest code from trunk.
> Now, when I do the make request from the gadget rendered from shindig on
> 8080, I get a null pointer exception because line 203 of
> OAuthAuthenticationHandler returns null and I get the error:
> "Cannot use disallowed Content-Type application/x-www-form-urlencoded
> description The request sent by the client was syntactically incorrect
> (Cannot use disallowed Content-Type application/x-www-form-urlencoded)"
>
> I saw the post on why x-www-form-urlencoded is no longer allowed, but my
> question is, how can I set the content type to application/json on the
> makeRequest? It seems like it should be pretty easy to have two shindigs
> talking to each other but somehow they started tripping over in the last
> week. Is there another secret setting on the OAuth decoder ring that I
> need to be aware of?
>
> Thanks (again) for all the help.
>
> -Mark W.
>
>
