You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Chris Chabot <ch...@xs4all.nl> on 2008/06/17 14:51:45 UTC
WARNING: PHP Shindig SecurityToken Breakage!
I hope that subject line got your attention :-)
The skinny is this: I've finished putting RESTful adapters into
Partuza, and i noticed there that the security token parsing was
having a major meltdown. Further investigation revealed that this was
due to the token being mangled differently in the rest code then in
the old wireformat code.
The solution was to base64_encode() the encrypted token on the
container side, and urldecode(base64_decode($token)) on the shindig
side.
So that means if you don't update your container's code to do the same
(base64_encode($st)) Shindig will no longer understand it, and you'll
see a lot of 'BAD GADGET TOKEN' type of errors.
I've updated both Shindig and Partuza, and tested both the old and new
wire format, and as long as you svn update them both things are
working peachy again.
Normally i really despise breaking deployments so my apologies for
that but unfortunately this change was unavoidable.
On to the good news! Yes there is good news too: http://partuza.us.chabotc.com/
is now in fact running the RESTful code! So if you want to take a
gander and kick the tires so to speak, go take a look!
-- Chris
Re: WARNING: PHP Shindig SecurityToken Breakage!
Posted by Kevin Brown <et...@google.com>.
On Tue, Jun 17, 2008 at 10:15 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> I do indeed, however it's a bit messier then that still.
>
> It looks (when checking out the iframe urls and social rest requests in
> firebug) that the token is urlencode(base64_encoded()) fine on the gadget
> url .. however the gadget it self has the urldecoded (but base64_ENcoded())
> in memory .. on making a social data request it uses the un-encoded (but
> base64 encoded) security token ... which at least in my tests on firefox 3
> and safari 3 automagically get encoded again..
>
> I guess kevin's suggestion for replacing + and ='s might be a way to go i
> guess
>
> How come this does automatically works for the java side (and i mean with
> real tokens and not plain text john.doe:jane.doe style ones, cause thats
> cheating! :)
We use a generic encoder that can take any arbitrary set of digits:
http://svn.apache.org/viewvc/incubator/shindig/trunk/java/common/src/main/java/org/apache/shindig/common/util/StringEncoding.java?revision=655698&view=markup
>
>
> -- Chris
>
>
> On Jun 17, 2008, at 7:08 PM, Ropu wrote:
>
> i think chris solution included the urlencode(), but not stated
>> implicitly... since all params are urlencoded when added to the iframe.
>> (you
>> can see the urldecode() in shindig)
>>
>
>
Re: WARNING: PHP Shindig SecurityToken Breakage!
Posted by Chris Chabot <ch...@xs4all.nl>.
I do indeed, however it's a bit messier then that still.
It looks (when checking out the iframe urls and social rest requests
in firebug) that the token is urlencode(base64_encoded()) fine on the
gadget url .. however the gadget it self has the urldecoded (but
base64_ENcoded()) in memory .. on making a social data request it uses
the un-encoded (but base64 encoded) security token ... which at least
in my tests on firefox 3 and safari 3 automagically get encoded again..
I guess kevin's suggestion for replacing + and ='s might be a way to
go i guess
How come this does automatically works for the java side (and i mean
with real tokens and not plain text john.doe:jane.doe style ones,
cause thats cheating! :)
-- Chris
On Jun 17, 2008, at 7:08 PM, Ropu wrote:
> i think chris solution included the urlencode(), but not stated
> implicitly... since all params are urlencoded when added to the
> iframe. (you
> can see the urldecode() in shindig)
Re: WARNING: PHP Shindig SecurityToken Breakage!
Posted by Ropu <ro...@gmail.com>.
i think chris solution included the urlencode(), but not stated
implicitly... since all params are urlencoded when added to the iframe. (you
can see the urldecode() in shindig)
>>>>> The solution was to base64_encode() the encrypted token on the
>>>>> container
>>>>> side, and urldecode(base64_decode($token)) on the shindig side.
ropu
On Tue, Jun 17, 2008 at 10:01 AM, Kevin Brown <et...@google.com> wrote:
> I wouldn't use php's standard bas64_encode for this -- it includes the +
> and
> = characters, which can cause problems unless you also urlencode the whole
> string. The standard workaround is to replace + with - and = with _ (or
> just
> drop =, since it's just the padding byte).
>
> On Tue, Jun 17, 2008 at 9:32 AM, Chris Chabot <ch...@xs4all.nl> wrote:
>
> > The main reason i'm not terribly eager about jumping into that right now
> is
> > because i remember a bug report some time about about the token not being
> > url encoded or bas64 encoded, and that broke some browser ... way i
> figure
> > is that by fixing the 'broken' behavior in this case, that bug (if it
> indeed
> > existed) should be eradicated too, without having to count on the
> browsers
> > always doing the RightThing(tm), which in practice never happens :)
> >
> > So in the end I'm happy with this solution, just in case there was a
> > possibility for a corner case type of bug it's gone now, and that makes
> me a
> > happy coder :)
> >
> > -- Chris
> >
> >
> > On Jun 17, 2008, at 6:19 PM, Cassie wrote:
> >
> > jsoncontainer line 120 and batchrequest.js line 30 and 43 put the
> security
> >> token in the post body in the old wire format. the only reason i wasn't
> >> doing this with rest is because we don't always post so atm i was
> sticking
> >> it in the url.
> >>
> >> I didn't have to change anything on the java side for this though.
> Anyway,
> >> the php works, which is good, but let me know if you want to dig deeper
> >> into
> >> finding out why :)
> >>
> >> - Cassie
> >>
> >>
> >> On Tue, Jun 17, 2008 at 9:01 AM, Chris Chabot <ch...@xs4all.nl>
> wrote:
> >>
> >> Not sure, else i would've fixed it on the javascript side :) I'm living
> >>> in
> >>> the impression that we parsed it along the url before somewhere too,
> and
> >>> that always seemed to go well ...but maybe i'm mistaken about that :)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Jun 17, 2008, at 5:55 PM, Cassie wrote:
> >>>
> >>> Is this just because we are passing the param along in the url as
> opposed
> >>>
> >>>> to
> >>>> the post body? Or is there some other change we made that I am
> >>>> forgetting?
> >>>>
> >>>> - Cassie
> >>>>
> >>>>
> >>>> On Tue, Jun 17, 2008 at 5:51 AM, Chris Chabot <ch...@xs4all.nl>
> >>>> wrote:
> >>>>
> >>>> I hope that subject line got your attention :-)
> >>>>
> >>>>>
> >>>>> The skinny is this: I've finished putting RESTful adapters into
> >>>>> Partuza,
> >>>>> and i noticed there that the security token parsing was having a
> major
> >>>>> meltdown. Further investigation revealed that this was due to the
> token
> >>>>> being mangled differently in the rest code then in the old wireformat
> >>>>> code.
> >>>>>
> >>>>> The solution was to base64_encode() the encrypted token on the
> >>>>> container
> >>>>> side, and urldecode(base64_decode($token)) on the shindig side.
> >>>>>
> >>>>> So that means if you don't update your container's code to do the
> same
> >>>>> (base64_encode($st)) Shindig will no longer understand it, and you'll
> >>>>> see
> >>>>> a
> >>>>> lot of 'BAD GADGET TOKEN' type of errors.
> >>>>>
> >>>>> I've updated both Shindig and Partuza, and tested both the old and
> new
> >>>>> wire
> >>>>> format, and as long as you svn update them both things are working
> >>>>> peachy
> >>>>> again.
> >>>>>
> >>>>> Normally i really despise breaking deployments so my apologies for
> that
> >>>>> but
> >>>>> unfortunately this change was unavoidable.
> >>>>>
> >>>>> On to the good news! Yes there is good news too:
> >>>>> http://partuza.us.chabotc.com/ is now in fact running the RESTful
> >>>>> code!
> >>>>> So
> >>>>> if you want to take a gander and kick the tires so to speak, go take
> a
> >>>>> look!
> >>>>>
> >>>>> -- Chris
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >
>
--
.-. --- .--. ..-
R o p u
Re: WARNING: PHP Shindig SecurityToken Breakage!
Posted by Kevin Brown <et...@google.com>.
I wouldn't use php's standard bas64_encode for this -- it includes the + and
= characters, which can cause problems unless you also urlencode the whole
string. The standard workaround is to replace + with - and = with _ (or just
drop =, since it's just the padding byte).
On Tue, Jun 17, 2008 at 9:32 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> The main reason i'm not terribly eager about jumping into that right now is
> because i remember a bug report some time about about the token not being
> url encoded or bas64 encoded, and that broke some browser ... way i figure
> is that by fixing the 'broken' behavior in this case, that bug (if it indeed
> existed) should be eradicated too, without having to count on the browsers
> always doing the RightThing(tm), which in practice never happens :)
>
> So in the end I'm happy with this solution, just in case there was a
> possibility for a corner case type of bug it's gone now, and that makes me a
> happy coder :)
>
> -- Chris
>
>
> On Jun 17, 2008, at 6:19 PM, Cassie wrote:
>
> jsoncontainer line 120 and batchrequest.js line 30 and 43 put the security
>> token in the post body in the old wire format. the only reason i wasn't
>> doing this with rest is because we don't always post so atm i was sticking
>> it in the url.
>>
>> I didn't have to change anything on the java side for this though. Anyway,
>> the php works, which is good, but let me know if you want to dig deeper
>> into
>> finding out why :)
>>
>> - Cassie
>>
>>
>> On Tue, Jun 17, 2008 at 9:01 AM, Chris Chabot <ch...@xs4all.nl> wrote:
>>
>> Not sure, else i would've fixed it on the javascript side :) I'm living
>>> in
>>> the impression that we parsed it along the url before somewhere too, and
>>> that always seemed to go well ...but maybe i'm mistaken about that :)
>>>
>>>
>>>
>>>
>>>
>>> On Jun 17, 2008, at 5:55 PM, Cassie wrote:
>>>
>>> Is this just because we are passing the param along in the url as opposed
>>>
>>>> to
>>>> the post body? Or is there some other change we made that I am
>>>> forgetting?
>>>>
>>>> - Cassie
>>>>
>>>>
>>>> On Tue, Jun 17, 2008 at 5:51 AM, Chris Chabot <ch...@xs4all.nl>
>>>> wrote:
>>>>
>>>> I hope that subject line got your attention :-)
>>>>
>>>>>
>>>>> The skinny is this: I've finished putting RESTful adapters into
>>>>> Partuza,
>>>>> and i noticed there that the security token parsing was having a major
>>>>> meltdown. Further investigation revealed that this was due to the token
>>>>> being mangled differently in the rest code then in the old wireformat
>>>>> code.
>>>>>
>>>>> The solution was to base64_encode() the encrypted token on the
>>>>> container
>>>>> side, and urldecode(base64_decode($token)) on the shindig side.
>>>>>
>>>>> So that means if you don't update your container's code to do the same
>>>>> (base64_encode($st)) Shindig will no longer understand it, and you'll
>>>>> see
>>>>> a
>>>>> lot of 'BAD GADGET TOKEN' type of errors.
>>>>>
>>>>> I've updated both Shindig and Partuza, and tested both the old and new
>>>>> wire
>>>>> format, and as long as you svn update them both things are working
>>>>> peachy
>>>>> again.
>>>>>
>>>>> Normally i really despise breaking deployments so my apologies for that
>>>>> but
>>>>> unfortunately this change was unavoidable.
>>>>>
>>>>> On to the good news! Yes there is good news too:
>>>>> http://partuza.us.chabotc.com/ is now in fact running the RESTful
>>>>> code!
>>>>> So
>>>>> if you want to take a gander and kick the tires so to speak, go take a
>>>>> look!
>>>>>
>>>>> -- Chris
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
Re: WARNING: PHP Shindig SecurityToken Breakage!
Posted by Chris Chabot <ch...@xs4all.nl>.
The main reason i'm not terribly eager about jumping into that right
now is because i remember a bug report some time about about the token
not being url encoded or bas64 encoded, and that broke some
browser ... way i figure is that by fixing the 'broken' behavior in
this case, that bug (if it indeed existed) should be eradicated too,
without having to count on the browsers always doing the
RightThing(tm), which in practice never happens :)
So in the end I'm happy with this solution, just in case there was a
possibility for a corner case type of bug it's gone now, and that
makes me a happy coder :)
-- Chris
On Jun 17, 2008, at 6:19 PM, Cassie wrote:
> jsoncontainer line 120 and batchrequest.js line 30 and 43 put the
> security
> token in the post body in the old wire format. the only reason i
> wasn't
> doing this with rest is because we don't always post so atm i was
> sticking
> it in the url.
>
> I didn't have to change anything on the java side for this though.
> Anyway,
> the php works, which is good, but let me know if you want to dig
> deeper into
> finding out why :)
>
> - Cassie
>
>
> On Tue, Jun 17, 2008 at 9:01 AM, Chris Chabot <ch...@xs4all.nl>
> wrote:
>
>> Not sure, else i would've fixed it on the javascript side :) I'm
>> living in
>> the impression that we parsed it along the url before somewhere
>> too, and
>> that always seemed to go well ...but maybe i'm mistaken about that :)
>>
>>
>>
>>
>>
>> On Jun 17, 2008, at 5:55 PM, Cassie wrote:
>>
>> Is this just because we are passing the param along in the url as
>> opposed
>>> to
>>> the post body? Or is there some other change we made that I am
>>> forgetting?
>>>
>>> - Cassie
>>>
>>>
>>> On Tue, Jun 17, 2008 at 5:51 AM, Chris Chabot <ch...@xs4all.nl>
>>> wrote:
>>>
>>> I hope that subject line got your attention :-)
>>>>
>>>> The skinny is this: I've finished putting RESTful adapters into
>>>> Partuza,
>>>> and i noticed there that the security token parsing was having a
>>>> major
>>>> meltdown. Further investigation revealed that this was due to the
>>>> token
>>>> being mangled differently in the rest code then in the old
>>>> wireformat
>>>> code.
>>>>
>>>> The solution was to base64_encode() the encrypted token on the
>>>> container
>>>> side, and urldecode(base64_decode($token)) on the shindig side.
>>>>
>>>> So that means if you don't update your container's code to do the
>>>> same
>>>> (base64_encode($st)) Shindig will no longer understand it, and
>>>> you'll see
>>>> a
>>>> lot of 'BAD GADGET TOKEN' type of errors.
>>>>
>>>> I've updated both Shindig and Partuza, and tested both the old
>>>> and new
>>>> wire
>>>> format, and as long as you svn update them both things are
>>>> working peachy
>>>> again.
>>>>
>>>> Normally i really despise breaking deployments so my apologies
>>>> for that
>>>> but
>>>> unfortunately this change was unavoidable.
>>>>
>>>> On to the good news! Yes there is good news too:
>>>> http://partuza.us.chabotc.com/ is now in fact running the RESTful
>>>> code!
>>>> So
>>>> if you want to take a gander and kick the tires so to speak, go
>>>> take a
>>>> look!
>>>>
>>>> -- Chris
>>>>
>>>>
>>>>
>>
Re: WARNING: PHP Shindig SecurityToken Breakage!
Posted by Cassie <do...@apache.org>.
jsoncontainer line 120 and batchrequest.js line 30 and 43 put the security
token in the post body in the old wire format. the only reason i wasn't
doing this with rest is because we don't always post so atm i was sticking
it in the url.
I didn't have to change anything on the java side for this though. Anyway,
the php works, which is good, but let me know if you want to dig deeper into
finding out why :)
- Cassie
On Tue, Jun 17, 2008 at 9:01 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> Not sure, else i would've fixed it on the javascript side :) I'm living in
> the impression that we parsed it along the url before somewhere too, and
> that always seemed to go well ...but maybe i'm mistaken about that :)
>
>
>
>
>
> On Jun 17, 2008, at 5:55 PM, Cassie wrote:
>
> Is this just because we are passing the param along in the url as opposed
>> to
>> the post body? Or is there some other change we made that I am forgetting?
>>
>> - Cassie
>>
>>
>> On Tue, Jun 17, 2008 at 5:51 AM, Chris Chabot <ch...@xs4all.nl> wrote:
>>
>> I hope that subject line got your attention :-)
>>>
>>> The skinny is this: I've finished putting RESTful adapters into Partuza,
>>> and i noticed there that the security token parsing was having a major
>>> meltdown. Further investigation revealed that this was due to the token
>>> being mangled differently in the rest code then in the old wireformat
>>> code.
>>>
>>> The solution was to base64_encode() the encrypted token on the container
>>> side, and urldecode(base64_decode($token)) on the shindig side.
>>>
>>> So that means if you don't update your container's code to do the same
>>> (base64_encode($st)) Shindig will no longer understand it, and you'll see
>>> a
>>> lot of 'BAD GADGET TOKEN' type of errors.
>>>
>>> I've updated both Shindig and Partuza, and tested both the old and new
>>> wire
>>> format, and as long as you svn update them both things are working peachy
>>> again.
>>>
>>> Normally i really despise breaking deployments so my apologies for that
>>> but
>>> unfortunately this change was unavoidable.
>>>
>>> On to the good news! Yes there is good news too:
>>> http://partuza.us.chabotc.com/ is now in fact running the RESTful code!
>>> So
>>> if you want to take a gander and kick the tires so to speak, go take a
>>> look!
>>>
>>> -- Chris
>>>
>>>
>>>
>
Re: WARNING: PHP Shindig SecurityToken Breakage!
Posted by Chris Chabot <ch...@xs4all.nl>.
Not sure, else i would've fixed it on the javascript side :) I'm
living in the impression that we parsed it along the url before
somewhere too, and that always seemed to go well ...but maybe i'm
mistaken about that :)
On Jun 17, 2008, at 5:55 PM, Cassie wrote:
> Is this just because we are passing the param along in the url as
> opposed to
> the post body? Or is there some other change we made that I am
> forgetting?
>
> - Cassie
>
>
> On Tue, Jun 17, 2008 at 5:51 AM, Chris Chabot <ch...@xs4all.nl>
> wrote:
>
>> I hope that subject line got your attention :-)
>>
>> The skinny is this: I've finished putting RESTful adapters into
>> Partuza,
>> and i noticed there that the security token parsing was having a
>> major
>> meltdown. Further investigation revealed that this was due to the
>> token
>> being mangled differently in the rest code then in the old
>> wireformat code.
>>
>> The solution was to base64_encode() the encrypted token on the
>> container
>> side, and urldecode(base64_decode($token)) on the shindig side.
>>
>> So that means if you don't update your container's code to do the
>> same
>> (base64_encode($st)) Shindig will no longer understand it, and
>> you'll see a
>> lot of 'BAD GADGET TOKEN' type of errors.
>>
>> I've updated both Shindig and Partuza, and tested both the old and
>> new wire
>> format, and as long as you svn update them both things are working
>> peachy
>> again.
>>
>> Normally i really despise breaking deployments so my apologies for
>> that but
>> unfortunately this change was unavoidable.
>>
>> On to the good news! Yes there is good news too:
>> http://partuza.us.chabotc.com/ is now in fact running the RESTful
>> code! So
>> if you want to take a gander and kick the tires so to speak, go
>> take a look!
>>
>> -- Chris
>>
>>
Re: WARNING: PHP Shindig SecurityToken Breakage!
Posted by Cassie <do...@apache.org>.
Is this just because we are passing the param along in the url as opposed to
the post body? Or is there some other change we made that I am forgetting?
- Cassie
On Tue, Jun 17, 2008 at 5:51 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> I hope that subject line got your attention :-)
>
> The skinny is this: I've finished putting RESTful adapters into Partuza,
> and i noticed there that the security token parsing was having a major
> meltdown. Further investigation revealed that this was due to the token
> being mangled differently in the rest code then in the old wireformat code.
>
> The solution was to base64_encode() the encrypted token on the container
> side, and urldecode(base64_decode($token)) on the shindig side.
>
> So that means if you don't update your container's code to do the same
> (base64_encode($st)) Shindig will no longer understand it, and you'll see a
> lot of 'BAD GADGET TOKEN' type of errors.
>
> I've updated both Shindig and Partuza, and tested both the old and new wire
> format, and as long as you svn update them both things are working peachy
> again.
>
> Normally i really despise breaking deployments so my apologies for that but
> unfortunately this change was unavoidable.
>
> On to the good news! Yes there is good news too:
> http://partuza.us.chabotc.com/ is now in fact running the RESTful code! So
> if you want to take a gander and kick the tires so to speak, go take a look!
>
> -- Chris
>
>