There is also a patch on jira that fixes this problem,
you can apply it to test oAuth (but maybe do not use it for production,
since the patch was not committed to shindig)
https://issues.apache.org/jira/browse/SHINDIG-1334
E.
On 25/8/10 10:48, Paul Lindner wrote:
yes, you'll need to escape the URL. Using colons for the sample security
token wasn't the best design decision. Alternatively you can change
"gadgets.securityTokenType" : "insecure",
to
"gadgets.securityTokenType" : "secure",
to use a secured token codec. This will encode the contents into something
that's more url escaping palatable.
On Mon, Aug 23, 2010 at 2:22 PM, Gregg Horan<gregg.ho...@dealer.com> wrote:
I'm just trying to run through some examples to understand how the oauth
works, and I'm curious about the secure token handling.
I encode the url that I put into the secureToken and verified that it
indeed goes out encoded in the raw request.
When I break in shindig BasicSecurityTokenDecoder, however, I see that it
has already unencoded the whole st/param for me, and subsequently blows up
trying to split on the ":" in the URL.
The only solution I came up with was to double encode the URL - which
actually seems to work, but seem a bit odd. Have I missed something or is
that really the way?
Thanks.
Gregg
