You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Gregg Horan <gr...@dealer.com> on 2010/08/23 23:22:34 UTC
BasicSecurityTokenDecoder unencodes then splits on ":"
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
Re: BasicSecurityTokenDecoder unencodes then splits on ":"
Posted by Evgeny Bogdanov <ev...@epfl.ch>.
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<gr...@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
>>
>>
>>
>
Re: BasicSecurityTokenDecoder unencodes then splits on ":"
Posted by Paul Lindner <pl...@linkedin.com>.
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 <gr...@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
>
>
>
--
Paul Lindner -- plindner@linkedin.com -- linkedin.com/in/plindner
Re: Should appData be per appId or per instance (appId:modId)?
Posted by Mat Mannion <M....@warwick.ac.uk>.
The way we've implemented it in our system is to have appData indexed
by (user, appId) and for userPrefs to be per-instance. So the
behaviour you describe, where appData is shared between two copies of
the app on their profile, is exactly how we've done it.
I must admit, though, that I can't for the life of me remember WHY I
implemented it that way, or have any reference as to the reasoning.
Regards,
Mat
On 26 August 2010 05:13, Gregg Horan <gr...@dealer.com> wrote:
> I'm trying to clarify if appData is supposed to be shared or distinct across multiple instances of the same gadget(appId) for a given user (per the opensocial standard).
>
> I have initially implemented appData and userPrefs as dinstinct per instance. Now I'm reading this wiki example and questioning that approach:
> http://wiki.opensocial.org/index.php?title=The_Persistence_API
> which describes an app that relies on exactly the opposite behavior... someone turns off a beep setting for a gadget in their own profile - then expects to reference that same setting when viewing the same gadget (app) when being viewed in another person's profile. That won't fly in my implementation. Conversely, if the person in that example puts two copies of that app on their profile, they have no way to configure them differently. So who's right?
>
> It's easy to go down one road or the other, but it would seem to be a core behavior that would be dictated by the spec. Have I missed it?
>
> Thanks
> Gregg
--
Mat Mannion
Web Developer
IT Services
University of Warwick
Coventry
CV4 7AL
Tel: 024 765 74433
Email: M.Mannion@warwick.ac.uk
Should appData be per appId or per instance (appId:modId)?
Posted by Gregg Horan <gr...@dealer.com>.
I'm trying to clarify if appData is supposed to be shared or distinct across multiple instances of the same gadget(appId) for a given user (per the opensocial standard).
I have initially implemented appData and userPrefs as dinstinct per instance. Now I'm reading this wiki example and questioning that approach:
http://wiki.opensocial.org/index.php?title=The_Persistence_API
which describes an app that relies on exactly the opposite behavior... someone turns off a beep setting for a gadget in their own profile - then expects to reference that same setting when viewing the same gadget (app) when being viewed in another person's profile. That won't fly in my implementation. Conversely, if the person in that example puts two copies of that app on their profile, they have no way to configure them differently. So who's right?
It's easy to go down one road or the other, but it would seem to be a core behavior that would be dictated by the spec. Have I missed it?
Thanks
Gregg