The token format can be anything you want ... as long as the container
is able to produce it, and the gadget server is able to read it.
It needs to contain the owner, viewer, app id, mod if, domain and
gadget url, see the existing token php files for reference.
If you wanted to make your own simply extend the token interface base
classes (SecurityTokenDecoder and SecurityToken), and add your code to
those ... add code to your container to generate it, and presto your
done..
However the easy path is to use the provided / default logic to create
and decode tokens, which you can generate in your container like done
here:
http://code.google.com/p/partuza/source/browse/trunk/Application/Views/gadget/gadget.php
(see the $securityToken = bit)
Now I'm almost positive that i linked that file to you before ... did
you take the time to read it and see what it does? I don't mind
answering questions after you have, but i would hope for some basic
level of self investigation..
-- Chris
On May 23, 2008, at 7:21 AM, Lini H - Clarion, India wrote:
Hi Chris,
I have one more query. If we encrypt our token, then is it like it
should be encrypted in a specific format only, if yes then whats the
format? Is the format used in the file BasicBlobCrypter the standard
one and we should follow that only?
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
----- Original Message -----
From: "Brian Eaton" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 23, 2008 12:45 AM
Subject: Re: Query regarding the security token
On Thu, May 22, 2008 at 9:27 AM, Gary Helmling
<[EMAIL PROTECTED]> wrote:
All that encryption adds is hiding the values themselves (owner id,
viewer id, module id, app id, domain, app url), which given the
values
and the fact that they're probably available in many other ways, I'm
wondering what the benefit of hiding those is.
You are absolutely correct that integrity is essential for the token,
and encryption may be optional.
As an example of why encryption may be useful consider Google: we
have
internal identifiers for users that we keep secret. We are willing
to
give gadgets an opaque identifier for the user, but not our real
internal identifier.
I suggest that everyone encrypt this token, for the following
reasons:
- opacity of the token keeps gadgets from making unsafe assumptions
about token format.
- sometimes there is confidential information in the token.
- encryption is easy and cheap. There is no down side.
If you have some particular environment where you can't use
encryption
for the token, that's fine, but please be cautious about recommending
that other people not encrypt. They are not necessarily working in
your environment.
Cheers,
Brian
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
