Just to be clear, to be "tamper proof" the token only needs to be properly signed. Encryption has the added benefit of keeping the data confidential, but is there any reason that most implementations would need that here?
Just wondering if there's something I'm missing. --Gary On Thu, May 22, 2008 at 3:36 AM, Chris Chabot <[EMAIL PROTECTED]> wrote: > The javascript sample files use a security token in the following format: > st=john.doe:john.doe:appid:cont:url:0 > > To be honest, that's only useful for examples, not for real world > applications ... since to be 'secure' it needs to be tamper proof, and clear > text clearly is not :) > > A real container would create a proper (encrypted) security token with a > private key the container / gadget server share, so that the token can be > verified for validity. the code you would see in > http://code.google.com/p/partuza/source/browse/trunk/Application/Views/gadget/gadget.php > is > a simple example of how to do that. > > -- Chris > > On May 22, 2008, at 9:09 AM, Lini H - Clarion, India wrote: > >> Hi Chris, >> >> I checked the script that creates the security token, both in the >> javascript gadget file as well as the php file. The php version encrypts the >> token using HMAC and base 64 whereas the security token is used directly in >> the javascript container gadget file. Now what problem does this difference >> will cause? >> >> Regards, >> Lini Haridas >> Software Engineer >> >> [EMAIL PROTECTED] >> Clarion Technologies >> SEI CMMI Level 3 Company >> >> 4th Floor, Great Eastern Plaza, >> Airport Road, >> Pune- 411 006, >> Maharashtra, India. >> Phone: +91 20 66020289 >> Mobile: +91 9823435917 >> www.clariontechnologies.co.in >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> > >
