Hi Chris,
I wanted to clarify something about the container implentation.
As per the opensocial specification v 0.8, following types of data requests are
supported:
FetchActivities
FetchPeople
FetchPersonAppData
FetchPerson
RemovePersonAppData
UpdatePersonAppData
Please correct me if I am wrong anywhere.
Now fetch people will fetch all the fields related to a single or set of users
that are stored in the SNS site. Similarly, fetch person will fetch the fields
of a single person. Now fetch activities will fetch all the activities of a
single or set of users. These activities will simply be text data stored in the
database whenever the user does something on one's profile.
Now I am confused with the App Data requests, whats exactly the type of data
that we can save for this?
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: "Chris Chabot" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 23, 2008 4:11 PM
Subject: Re: Query regarding the security token
> 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.
>>
>
>
> --
> 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.
