You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Lini H - Clarion, India" <li...@clariontechnologies.co.in> on 2008/05/22 09:09:51 UTC
Query regarding the security token
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
lini.haridas@clariontechnologies.co.in
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.
Re: Query regarding the security token
Posted by Chris Chabot <ch...@xs4all.nl>.
Shindig includes a sample container handler (xml file driven) that
shows all the logic:
http://svn.apache.org/repos/asf/incubator/shindig/trunk/php/src/socialdata/samplecontainer/
The idea is that a container would create their own handler, edit the
shindig/php/src/config.php and edit the 'handlers' => '' line, put in
your class name there .. put the classes in the path shindig searches
(for instance shindig/php/src/socialdata seems an appropriate place),
and your all set.
There's a DB driven example handler in partuza:
http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaHandler.php
http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaDbFetcher.php
At the moment the code is the documentation, so thats where you'd find
it :)
-- Chris
On May 23, 2008, at 9:11 AM, Lini H - Clarion, India wrote:
>
> 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.
>
Re: Query regarding the security token
Posted by "Lini H - Clarion, India" <li...@clariontechnologies.co.in>.
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
lini.haridas@clariontechnologies.co.in
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" <ch...@xs4all.nl>
To: <sh...@incubator.apache.org>
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
>>
>> lini.haridas@clariontechnologies.co.in
>> 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" <ch...@xs4all.nl>
>> To: <sh...@incubator.apache.org>
>> 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
>>>>
>>>> lini.haridas@clariontechnologies.co.in
>>>> 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" <ch...@xs4all.nl>
>>>> To: <sh...@incubator.apache.org>
>>>> 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
>>>>>>
>>>>>> lini.haridas@clariontechnologies.co.in
>>>>>> 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.
Re: Query regarding the security token
Posted by Chris Chabot <ch...@xs4all.nl>.
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
>
> lini.haridas@clariontechnologies.co.in
> 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" <ch...@xs4all.nl>
> To: <sh...@incubator.apache.org>
> 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
>>>
>>> lini.haridas@clariontechnologies.co.in
>>> 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" <ch...@xs4all.nl>
>>> To: <sh...@incubator.apache.org>
>>> 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
>>>>>
>>>>> lini.haridas@clariontechnologies.co.in
>>>>> 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.
>
Re: Query regarding the security token
Posted by "Lini H - Clarion, India" <li...@clariontechnologies.co.in>.
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
lini.haridas@clariontechnologies.co.in
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" <ch...@xs4all.nl>
To: <sh...@incubator.apache.org>
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
>>
>> lini.haridas@clariontechnologies.co.in
>> 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" <ch...@xs4all.nl>
>> To: <sh...@incubator.apache.org>
>> 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
>>>>
>>>> lini.haridas@clariontechnologies.co.in
>>>> 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.
Re: Query regarding the security token
Posted by Chris Chabot <ch...@xs4all.nl>.
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
>
> lini.haridas@clariontechnologies.co.in
> 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" <ch...@xs4all.nl>
> To: <sh...@incubator.apache.org>
> 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
>>>
>>> lini.haridas@clariontechnologies.co.in
>>> 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.
>
Re: Query regarding the security token
Posted by "Lini H - Clarion, India" <li...@clariontechnologies.co.in>.
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
lini.haridas@clariontechnologies.co.in
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" <ch...@xs4all.nl>
To: <sh...@incubator.apache.org>
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
>>
>> lini.haridas@clariontechnologies.co.in
>> 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.
Re: Query regarding the security token
Posted by Chris Chabot <ch...@xs4all.nl>.
This page documents the persistent data storage (aka app data) from
the client API point of view:
http://code.google.com/apis/opensocial/docs/0.7/devguide.html#Persistent
-- Chris
On May 29, 2008, at 5:49 AM, Lini H - Clarion, India wrote:
> Now I am confused with the App Data requests, whats exactly the type
> of data that we can save for this?
Re: Query regarding the security token
Posted by "Lini H - Clarion, India" <li...@clariontechnologies.co.in>.
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
lini.haridas@clariontechnologies.co.in
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" <ch...@xs4all.nl>
To: <sh...@incubator.apache.org>
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
>>
>> lini.haridas@clariontechnologies.co.in
>> 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" <be...@google.com>
>> To: <sh...@incubator.apache.org>
>> 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
>>> <gh...@gmail.com> 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.
Re: Query regarding the security token
Posted by Chris Chabot <ch...@xs4all.nl>.
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
>
> lini.haridas@clariontechnologies.co.in
> 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" <be...@google.com>
> To: <sh...@incubator.apache.org>
> 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
>> <gh...@gmail.com> 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.
>
Re: Query regarding the security token
Posted by "Lini H - Clarion, India" <li...@clariontechnologies.co.in>.
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
lini.haridas@clariontechnologies.co.in
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" <be...@google.com>
To: <sh...@incubator.apache.org>
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 <gh...@gmail.com> 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.
Re: Query regarding the security token
Posted by Brian Eaton <be...@google.com>.
On Thu, May 22, 2008 at 9:27 AM, Gary Helmling <gh...@gmail.com> 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
Re: Query regarding the security token
Posted by Gary Helmling <gh...@gmail.com>.
As long as you verify the signature on the token, any edits made to
the text will fail validation (since the new values will generate a
different signature). So the signature itself prevents this kind of
abuse. Encryption of the signed values is not necessary for
verification.
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.
--Gary
On Thu, May 22, 2008 at 12:10 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> Absolutely.
>
> Say that you have a gadget "i have a crush on", and someone fakes being you
> (since the token is plain text thats easy, just replace a number), and lists
> you as having a crush on your boss ..... embarrassing!
>
> And that's just from a 'silly game' point of view, imagine you had a
> business app that you used to schedule meetings, someone faking your ID
> could spam "buy <member enlarging medicine> at this site!" to all your
> business contacts... thats beyond embarrassing, that's a business risk!
>
> Absolutely worst case, you have some gadget that is linked to some financial
> source like a credit card, the potential damages there are huge.
>
> So yes ... verifiable identity and making this identity tamper proof is
> serious business and absolutely required in any real life situations.
>
> -- Chris
>
> On May 22, 2008, at 5:24 PM, Gary Helmling wrote:
>
>> is there any reason that most implementations would
>> need that here?
>
>
Re: Query regarding the security token
Posted by Chris Chabot <ch...@xs4all.nl>.
Absolutely.
Say that you have a gadget "i have a crush on", and someone fakes
being you (since the token is plain text thats easy, just replace a
number), and lists you as having a crush on your boss .....
embarrassing!
And that's just from a 'silly game' point of view, imagine you had a
business app that you used to schedule meetings, someone faking your
ID could spam "buy <member enlarging medicine> at this site!" to all
your business contacts... thats beyond embarrassing, that's a business
risk!
Absolutely worst case, you have some gadget that is linked to some
financial source like a credit card, the potential damages there are
huge.
So yes ... verifiable identity and making this identity tamper proof
is serious business and absolutely required in any real life situations.
-- Chris
On May 22, 2008, at 5:24 PM, Gary Helmling wrote:
> is there any reason that most implementations would
> need that here?
Re: Query regarding the security token
Posted by Ropu <ro...@gmail.com>.
Thats right
Security issues are solved with the signature, encryption *only *add
privacy.
That class was coded that way so tokens are 'exchangeable' with java
implementation, but there is no standard (that im aware of) in OS spec that
describes how the token MUST be.
hope this helps
ropu
On Thu, May 22, 2008 at 12:24 PM, Gary Helmling <gh...@gmail.com> wrote:
> 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 <ch...@xs4all.nl> 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.phpis
> > 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
> >>
> >> lini.haridas@clariontechnologies.co.in
> >> 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.
> >>
> >
> >
>
--
.-. --- .--. ..-
R o p u
Re: Query regarding the security token
Posted by Gary Helmling <gh...@gmail.com>.
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 <ch...@xs4all.nl> 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
>>
>> lini.haridas@clariontechnologies.co.in
>> 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.
>>
>
>
Re: Query regarding the security token
Posted by Chris Chabot <ch...@xs4all.nl>.
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
>
> lini.haridas@clariontechnologies.co.in
> 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.
>