Hi Chris,
So now the requests that we would entertain will solely depend on our
opensocial data implementation. Now I wanted to know where are all the request
types field names defined. Say for e.g. to get the friends of the owner, the
request handler is "FETCH_PEOPLE" and the type is "OWNER_FRIENDS", where are
these values defined as they define the course of actions to be taken by the
database.
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: Thursday, May 22, 2008 10:09 PM
Subject: Re: Query regarding the security token
> OpenSocial doesn't say which fields you have to support, it is
> actually completely according to spec to reply notImplemented to all
> requests (though it wouldn't make for very interesting apps).
>
> So with that in mind, you can choose to support any of the data types
> defined in:
> http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.html
>
> You will find the PHP models for these data types in <trunk>/php/src/
> socialdata/opensocial/model/*.php
> I took a stab at interpreting them in mysql schema in:
> http://code.google.com/p/partuza/source/browse/trunk/partuza.sql
>
> Make your own social data handlers, and map what you can to your own
> data format, and just returning notImplemented to whatever you can't
> map and you should be good to go.
>
> Also take a look at <trunk>/config/container.js, specifically this bit:
> "supportedFields" : {
> "person" : ["id", "name", "thumbnailUrl", "profileUrl"],
> "activity" : ["id", "title"]
>
> there you can configure which fields you do support for your person
> and activity entries btw. id, name, thumbnail url and profile url are
> probably the min amount of data you want to support to have useful
> gadgets :)
>
> -- Chris
>
> On May 22, 2008, at 1:59 PM, Lini H - Clarion, India wrote:
>
>> Hi Chris,
>>
>> I have one more query regarding the container. Now as per the
>> opensocial API, there will be loads of applications developed which
>> will require the SNS data. So what do we have to keep in mind while
>> coding the db related functions in the container?
>>
>> 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: Thursday, May 22, 2008 1:42 PM
>> Subject: Re: Query regarding the security token
>>
>>
>>> See this bit in the <trunk>/php/config.php:
>>>
>>> // The html / javascript samples use a plain text demo token,
>>> // set this to false on anything resembling a real site
>>> 'allow_plaintext_token' => true,
>>>
>>>
>>> On May 22, 2008, at 10:07 AM, Lini H - Clarion, India wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> Ok now both ways, i.e the iframe generated in php or by the
>>>> javascript, the request is sent to the shindig server, which will
>>>> accept and process the token. So will it process both the encrypted
>>>> as well as the plain text token?
>>>>
>>>> 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: Thursday, May 22, 2008 1:06 PM
>>>> Subject: Re: Query regarding the security token
>>>>
>>>>
>>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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.
>>
>
>
> --
> 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.
