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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>>> 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 >>>>> >>>>> >>>>> >>>>> >>> >
