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
