You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Chris Chabot <ch...@xs4all.nl> on 2008/04/10 23:52:19 UTC
OAuth broke socialdata interface
Hey Guys,
I've noticed that the recent OAuth patches broke the social data part
of shindig in the sample container situation.
When i run the http://opensocial-resources.googlecode.com/svn/tests/trunk/compliancetests.xml
in it, i get an error on the console (included @ the bottom of the
mail) because of the empty security token (st in the post) in those
social data requests makes it quite upset :)
Now i guess the best way to fix this is by actually have a valid
security token, but in static html sample files that might be tricky
Maybe we can hook them up to the RPC service of shindig and have it
generate a valid security token? I quickly ran this idea by Cassie at
the apache con yesterday and her response was along the lines of "Yes
that seems the best way to fix it ... who ever broke it should do
that", so i guess that would be you Brian? :)
That leaves me with the question what i would have to do to make that
work with the PHP version too, haven't started on the OAuth part yet
(been working hard on the social data part of things), anyone have an
overview for me what the minimal thing is i need to create to make it
work, preferable in a wire format compatible way so that components of
the java and php land can still be used side by side?
Reproducing this is simple ... hook up the compliancetests.xml in
sampe1.html for instance, and inspect at the json replies in firebug
The Backtrace on the console:
2008-04-10 23:40:33.973::WARN: /gadgets/socialdata
java.lang.ArrayIndexOutOfBoundsException: 1
at
org
.apache
.shindig
.gadgets
.BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:47)
at
org
.apache
.shindig
.social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
at
org
.apache.shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:
80)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org
.mortbay
.jetty
.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:
206)
at
org
.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:
114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection
$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at
org
.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
395)
at org.mortbay.thread.BoundedThreadPool
$PoolThread.run(BoundedThreadPool.java:450)
The html page in the json reply (which btw is a bug on its self too,
this should be a nice json error and not a html backtrace rigtht? :P)
is much the same:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1"/>
<title>Error 500 1</title>
</head>
<body><h2>HTTP ERROR: 500</h2><pre>1</pre>
<p>RequestURI=/gadgets/socialdata</p><h3>Caused by:</
h3><pre>java.lang.ArrayIndexOutOfBoundsException
: 1
at
org
.apache
.shindig
.gadgets
.BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:47)
at
org
.apache
.shindig
.social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
at
org
.apache.shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:
80)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:
487)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:
216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
405)
at
org
.mortbay
.jetty
.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:
206)
at
org
.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:
114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
505)
at org.mortbay.jetty.HttpConnection
$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at
org
.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
395)
at org.mortbay.thread.BoundedThreadPool
$PoolThread.run(BoundedThreadPool.java:450)
</pre>
<p><i><small><a href="http://jetty.mortbay.org/">Powered by Jetty://</
a></small></i></p><br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
<br/>
</body>
</html>
Re: OAuth broke socialdata interface
Posted by Chris Chabot <ch...@xs4all.nl>.
Could we make this a john.doe:john.doe btw for the owner / viewer
fields?
This to make it work well with the sample data in state-
basicfriendlist.xml
-- Chris
On Apr 11, 2008, at 8:14 AM, Brian Eaton wrote:
> OK, patch attached.
>
> Maybe we should update the sample socialdata servlets so they can
> return a security token for the gadget when the gadget renders? I'm
> not sure where that servlet would hook in, but if someone tells me
> where it should go (on the server) and where it should be called from
> (on the sample container pages), the actual code is pretty simple.
>
> Or maybe that's not what the sample servlets are for. I don't
> really know.
>
> Cheers,
> Brian
>
> On Thu, Apr 10, 2008 at 3:26 PM, Kevin Brown <et...@google.com> wrote:
>> The BasicTokenDecoder interface is actually incredibly lame, so a
>> static
>> token would be possible. The format is something like app id :
>> owner id :
>> viewer id : domain. This was done intentionally for this sort of
>> testing. We
>> probably need to update the sample page for this.
>>
>>
>>
>> On Thu, Apr 10, 2008 at 2:52 PM, Chris Chabot <ch...@xs4all.nl>
>> wrote:
>>
>>> Hey Guys,
>>>
>>> I've noticed that the recent OAuth patches broke the social data
>>> part of
>>> shindig in the sample container situation.
>>>
>>> When i run the
>>> http://opensocial-resources.googlecode.com/svn/tests/trunk/compliancetests.xml
>>> in
>>> it, i get an error on the console (included @ the bottom of the
>>> mail)
>>> because of the empty security token (st in the post) in those
>>> social data
>>> requests makes it quite upset :)
>>>
>>> Now i guess the best way to fix this is by actually have a valid
>>> security
>>> token, but in static html sample files that might be tricky
>>>
>>> Maybe we can hook them up to the RPC service of shindig and have it
>>> generate a valid security token? I quickly ran this idea by Cassie
>>> at the
>>> apache con yesterday and her response was along the lines of "Yes
>>> that seems
>>> the best way to fix it ... who ever broke it should do that", so i
>>> guess
>>> that would be you Brian? :)
>>>
>>> That leaves me with the question what i would have to do to make
>>> that work
>>> with the PHP version too, haven't started on the OAuth part yet
>>> (been
>>> working hard on the social data part of things), anyone have an
>>> overview for
>>> me what the minimal thing is i need to create to make it work,
>>> preferable in
>>> a wire format compatible way so that components of the java and
>>> php land can
>>> still be used side by side?
>>>
>>>
>>> Reproducing this is simple ... hook up the compliancetests.xml in
>>> sampe1.html for instance, and inspect at the json replies in firebug
>>>
>>> The Backtrace on the console:
>>>
>>> 2008-04-10 23:40:33.973::WARN: /gadgets/socialdata
>>> java.lang.ArrayIndexOutOfBoundsException: 1
>>> at
>>> org
>>> .apache
>>> .shindig
>>> .gadgets
>>> .BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:
>>> 47)
>>> at
>>> org
>>> .apache
>>> .shindig
>>> .social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
>>> at
>>> org
>>> .apache
>>> .shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:80)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:
>>> 727)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:
>>> 820)
>>> at
>>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:
>>> 487)
>>> at
>>> org
>>> .mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:
>>> 362)
>>> at
>>> org
>>> .mortbay
>>> .jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>>> at
>>> org
>>> .mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:
>>> 181)
>>> at
>>> org
>>> .mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:
>>> 726)
>>> at
>>> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
>>> 405)
>>> at
>>> org
>>> .mortbay
>>> .jetty
>>> .handler
>>> .ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
>>> at
>>> org
>>> .mortbay
>>> .jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>>> at
>>> org
>>> .mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:
>>> 139)
>>> at org.mortbay.jetty.Server.handle(Server.java:324)
>>> at
>>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
>>> 505)
>>> at
>>> org.mortbay.jetty.HttpConnection
>>> $RequestHandler.content(HttpConnection.java:842)
>>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
>>> at
>>> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>>> at
>>> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>>> at
>>> org
>>> .mortbay
>>> .io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
>>> at
>>> org.mortbay.thread.BoundedThreadPool
>>> $PoolThread.run(BoundedThreadPool.java:450)
>>>
>>> The html page in the json reply (which btw is a bug on its self
>>> too, this
>>> should be a nice json error and not a html backtrace rigtht? :P)
>>> is much the
>>> same:
>>>
>>> <html>
>>> <head>
>>> <meta http-equiv="Content-Type" content="text/html;
>>> charset=ISO-8859-1"/>
>>> <title>Error 500 1</title>
>>> </head>
>>> <body><h2>HTTP ERROR: 500</h2><pre>1</pre>
>>> <p>RequestURI=/gadgets/socialdata</p><h3>Caused
>>> by:</h3><pre>java.lang.ArrayIndexOutOfBoundsException
>>> : 1
>>> at
>>> org
>>> .apache
>>> .shindig
>>> .gadgets
>>> .BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:
>>> 47)
>>> at
>>> org
>>> .apache
>>> .shindig
>>> .social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
>>> at
>>> org
>>> .apache
>>> .shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:80)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:
>>> 727)
>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:
>>> 820)
>>> at
>>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:
>>> 487)
>>> at
>>> org
>>> .mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:
>>> 362)
>>> at
>>> org
>>> .mortbay
>>> .jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>>> at
>>> org
>>> .mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:
>>> 181)
>>> at
>>> org
>>> .mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:
>>> 726)
>>> at
>>> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:
>>> 405)
>>> at
>>> org
>>> .mortbay
>>> .jetty
>>> .handler
>>> .ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
>>> at
>>> org
>>> .mortbay
>>> .jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>>> at
>>> org
>>> .mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:
>>> 139)
>>> at org.mortbay.jetty.Server.handle(Server.java:324)
>>> at
>>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:
>>> 505)
>>> at
>>> org.mortbay.jetty.HttpConnection
>>> $RequestHandler.content(HttpConnection.java:842)
>>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
>>> at
>>> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>>> at
>>> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>>> at
>>> org
>>> .mortbay
>>> .io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
>>> at
>>> org.mortbay.thread.BoundedThreadPool
>>> $PoolThread.run(BoundedThreadPool.java:450)
>>> </pre>
>>> <p><i><small><a href="http://jetty.mortbay.org/">Powered by
>>> Jetty://</a></small></i></p><br/>
>>>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> <br/>
>>> </body>
>>> </html>
>>>
>>
>>
>>
>> --
>> ~Kevin
>>
> <faketoken.patch>
Re: OAuth broke socialdata interface
Posted by Kevin Brown <et...@google.com>.
On Sat, Apr 12, 2008 at 12:50 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> Well the problem I could see with this (the container creating 'some'
> security token), is that other parts of shindig (such as the socialdata
> part) will use the standard blob decrypter to decrypt it, and expect a
> valid
> array with viewer / owner / module id / app id / domain information
>
> So take the situation where someone is using the RPC service to create a
> iframe url, you would probably do this because your not writing java
> servlets right, but would rather use shindig as a 'black box'.
>
> In that scenario you would have no way to generate a security token that
> would work with the other parts of shindig (i.a.w. socialdata) , and you
> would be forced to write some java code anyhow ... which departs from the
> black box concept.
No, you wouldn't. The encrypted blob is extremely simple, and the code to
create the tokens can be generated trivially in any programming language
that has a decent encryption library (PHP, Python, Ruby, C++, and Perl are
all definitely covered; I'm sure most others are as well).
I'm proposing that we have to GadgetTokenDecoders in shindig java:
1. A plain text token, used for debugging
2. An encrypted token, using the same format as the plain text, just
encrypted using an appropriate key
A configuration setting will determine which one is used by default.
We're not inventing a new crypto algorithm here, so compatibility between
languages is trivial.
--
~Kevin
UserPref not working
Posted by Sanjay Shende <Sa...@symphonysv.com>.
Hi All,
I am unable to get the Preferences settings window. I have added
3-4 preferences using "UserPref" tag, but when I click on "Settings"
link, nothing is being displayed. Can someone let me know how to make
these preferences working, Because I need them urgently in my gadget. I
am using java version of Shindig.
Regards,
Sanjay
"This email and any files transmitted with it contain confidential, proprietary,
privileged information of Symphony Services Corp (India) Pvt. Ltd. and are intended
solely for the use of the recipient/s to whom it is addressed. Any unauthorized
notifying, copying or distributing of this e-mail, directly or indirectly, and the
contents therein in full or part is prohibited by any entity who is not a recipient.
Any email received inadvertently or by mistake should be deleted by the entity who
is not a recipient thereof. You may be pleased to notify the sender immediately by
email and the email should be deleted from your system".
Re: Security tokens & crypto (was: OAuth broke socialdata interface)
Posted by Chris Chabot <ch...@xs4all.nl>.
Thanks that explained a few things, i'll get right on this then :)
On Apr 13, 2008, at 7:02 PM, Brian Eaton wrote:
>
> +1. If you port the BlobCrypter code to PHP, we're most of the way
> there.
>
>
Re: Security tokens & crypto (was: OAuth broke socialdata interface)
Posted by Brian Eaton <be...@google.com>.
A few comments inline.
On Sun, Apr 13, 2008 at 4:20 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> One other thing, would it be possible to use a public / private key pair for
> this, preferably something generated by openssl ?
Asymmetric might be useful for this, but bear in mind it is about
1000x slower than symmetric crypto. Unless you have a pressing reason
for wanting the gadget server to be able to verify tokens, but not
generate them, don't use public key.
If you do use public key, you probably want a mix of public and
symmetric key crypto. The first time the gadget server sees a public
key signed token, it should replace the public key key signature with
a symmetric version using a key known only to the gadget server. That
way subsequent uses of the same token can be verified quickly.
Also consider whether you want just integrity, or integrity +
confidentiality. (Should the gadget be able to peek at the gadget
security token and see exactly what's inside?) The BlobCrypter code
provides both.
> To be able to do that, they'd have to be able to continue to understand
> each other and have exactly the same wire format, including security tokens
> and encryption, using an [openssl or compatible] type of encryption would
> guarantee both sides of the fence are able to produce and consume the tokens
> seamlessly, well that would be the ideal situation for me anyhow.
+1. I wrote the BlobCrypter code using a very simple wire format
(x-www-form-urlencoded, pretty much) and common algorithms for exactly
this reason.
> I've done a quick test, generating some keys and encrypting the token with
> it, and the end result is a 128 byte long (binary) string, urlencode it and
> you end up having security token weighing in at 324 bytes my this test
> case...
Base64 encoding is much more efficent than URL encoding for binary
data. Overhead for BlobCrypter should be
+16 bytes for initial vector
+20 bytes for HMAC
+0-16 bytes for padding (uggh, might be wrong on that)
x1.33 for base64 encoding
> So I'm not a 100% sure yet about what the ideal, working solution would
> be.. but it would be nice if the java and php versions understood each
> other's tokens, and it would be nice as well if this default implementation
> was cryptographically sound;
+1. If you port the BlobCrypter code to PHP, we're most of the way there.
> Plus if the token generation used a
> public/private key pair, it could well use the same key's as the signing /
> oath code, which need to be generated anyhow for anyone who will use shindig
> right?
Reusing keys for different purposes tends to be a bad idea. We should
have distinct keys for signed fetch vs gadget security token because:
a) we will sign arbitrary messages with the signed fetch key. If
someone can make us sign a message that looks like a gadget security
token, they can replay the message as if it actually were a gadget
security token.
b) the signed fetch key can change very rarely. The gadget
security token key is free to change much more often because it is
only used within a single organization.
c) signed fetch will always be RSA signing. The gadget security
token can use any algorithm we please, to optimize for speed, or size,
or security, or all of the above.
Cheers,
Brian
Security tokens & crypto (was: OAuth broke socialdata interface)
Posted by Chris Chabot <ch...@xs4all.nl>.
One other thing, would it be possible to use a public / private key
pair for this, preferably something generated by openssl ?
I've heard of some people that they might be interested in a mix of
the java and php versions of shindig, where they would use the shindig
java server for rendering the gadgets through the RPC service, but
would like to use the php social data part so they can add their data
code there.
To be able to do that, they'd have to be able to continue to
understand each other and have exactly the same wire format, including
security tokens and encryption, using an [openssl or compatible] type
of encryption would guarantee both sides of the fence are able to
produce and consume the tokens seamlessly, well that would be the
ideal situation for me anyhow.
I've done a quick test, generating some keys and encrypting the token
with it, and the end result is a 128 byte long (binary) string,
urlencode it and you end up having security token weighing in at 324
bytes my this test case... So i have some doubts if we can pass that
through the url's without any problems? (i forgot what the arbitrary
length restriction imposed by various browsers is now-a-days, but i
know you can't put to much data on the url without some of them
truncating it at their leisure)
So I'm not a 100% sure yet about what the ideal, working solution
would be.. but it would be nice if the java and php versions
understood each other's tokens, and it would be nice as well if this
default implementation was cryptographically sound; Plus if the token
generation used a public/private key pair, it could well use the same
key's as the signing / oath code, which need to be generated anyhow
for anyone who will use shindig right?
The quick-test consisted out of:
# openssl genrsa -out private-key.pem 1024
# openssl req -new -key private-key.pem -x509 -days 365 -out public-
key.pem
en-decrypt.php:
#!/usr/bin/php -Cq
<?php
// encrypt token
$input = "john.doe:john.doe:appid:synd:url:0";
$fp=fopen ("private-key.pem", "r");
$priv_key=fread ($fp, 8192);
fclose($fp);
openssl_get_privatekey ($priv_key);
openssl_private_encrypt($input, $crypted, $priv_key);
echo "Crypted len: ".strlen($crypted).". urlencoded len:
".strlen(urlencode($crypted))."\n";
// decrypt again to validate operations
$fp = fopen("public-key.pem","r");
$pub_key = fread($fp,8192);
fclose($fp);
openssl_get_publickey ($pub_key);
openssl_public_decrypt ($crypted, $decrypted, $pub_key);
echo "decrypted: $decrypted\n";
?>
output:
Crypted len: 128. urlencoded len: 324
decrypted: john.doe:john.doe:appid:synd:url:0
On Apr 12, 2008, at 9:50 PM, Chris Chabot wrote:
> Well the problem I could see with this (the container creating 'some'
> security token), is that other parts of shindig (such as the
> socialdata
> part) will use the standard blob decrypter to decrypt it, and expect
> a valid
> array with viewer / owner / module id / app id / domain information
>
> So take the situation where someone is using the RPC service to
> create a
> iframe url, you would probably do this because your not writing java
> servlets right, but would rather use shindig as a 'black box'.
>
> In that scenario you would have no way to generate a security token
> that
> would work with the other parts of shindig (i.a.w. socialdata) , and
> you
> would be forced to write some java code anyhow ... which departs
> from the
> black box concept.
>
> Disclaimer 1: I'm just going by the current java code, where the
> gadget data
> servlet takes the st param, decrypts it using the basic blob crypter
> logic,
> and uses the owner and viewer data from it to generate the isViewer /
> isOwner and friend list information.
>
> Disclaimer 2: I'm assuming that the RPC service is still meant to
> allow
> shindig to be used in a 'black box' type scenario, where shindig
> creates
> your iframe url's, renders the gadgets and provides a gateway to an
> external
> social data source. Based on this assumption this scenario -should-
> work
> with a security token that is created, consumed and meaningful inside
> shindig.
>
> -- Chris
>
> -----Original Message-----
> From: Kevin Brown [mailto:etnu@google.com]
> Sent: Saturday, April 12, 2008 21:29
> To: shindig-dev@incubator.apache.org
> Subject: Re: OAuth broke socialdata interface
>
> Er -- one additional thing. If we *do* allow the metadata servlet to
> generate security tokens, we must then layer another protection
> mechanism on
> top of it. I honestly have no idea what would be appropriate here.
> Normally
> you'd use cookies, but that's not really viable here.
>
> With that in mind, having the consuming container generate the
> security
> tokens and attaching them to the metadata-produced iframes is
> probably still
> the best option.
>
> On Sat, Apr 12, 2008 at 12:26 PM, Kevin Brown <et...@google.com> wrote:
>
>> On Sat, Apr 12, 2008 at 3:11 AM, Chris Chabot <ch...@xs4all.nl>
>> wrote:
>>
>>> What i imagine should happen is that:
>>>
>>> 1) The PRC service (see RpcServlet and jsonRpcHandler, etc) which
>>> generates a iframe url, is modified to include the proper st=
>>> security
> token
>>> in that url. We should be able to tell the the rpc service who our
>>> viewer/owner/domain is, is this already in place? (haven't written
>>> that
> yet
>>> on the php side so my knowledge is lacking there)
>>
>>
>> I'm still not sure which way is the right way to go on this one.
>> Putting
>> this into the metadata handler would make sense (and the wiring is
>> mostly
>> there), but on the other hand I think it might be more natural for
>> the
>> metadata handler to return the "raw" url, and allow consumers of the
>> metadata handler to append the security token. This makes it much
>> easier
> to
>> isolate ownership of encryption keys.
>>
>> Of course, this makes using the metadata handlers directly from
>> client
>> side javascript (via XHR) harder. I wonder if many people will
>> actually be
>> using this in the "real world" though -- I certainly didn't build
>> it with
>> that in mind. I assumed most people would hit the metadata servlet
>> from
>> their existing site.
>>
>> I'm more than happy to support both if there's enough demand from
>> users.
>> We'd simply not generate st if the appropriate inputs are missing.
>>
>> 2) We rewrite the examples / sample container to use this RPC
>> service (see
>>> javascript/container and javascript/samplecontainer). We should be
>>> able
> to
>>> tell it the owner, viewer and module id, plus the domain (which we
>>> can
>>> easily retrieve in javascript in the examples). In the examples this
> would
>>> be john.doe x2, the incremental module id it generates, and the
>>> domain
> from
>>> the current document; But any container-to-be would just modify this
> code
>>> and put the (site) authenticated owner and viewer here instead,
>>> and be
> done
>>> with it :)
>>
>>
>> Agreed that this should be done (I could have sworn that I opened a
>> JIRA
>> ticket to do this).
>>
>>
>>> This way it should just work out of the box for anyone trying out
>>> the
>>> examples & sample container, and more importantly, if they use
>>> this as a
>>> basis of their own container they will actually have a somewhat
>>> working
> and
>>> secure setup that wouldn't allow their users to spoof identities and
> 'hack'
>>> the gadgets.
>>>
>>> My concern for this was inspired by some of the apache guys at the
>>> ApacheCon, who in our meet-up mentioned "With <this other project>
>>> we
> supply
>>> a basic example that people take and build upon and expand to make
>>> their
> own
>>> site", and i think that is how people will probably end up using
>>> shindig
> too
>>> in the long run. Right now it is a pretty 'controller' environment
>>> still
> and
>>> we can afford some basic assumptions about what people should and
>>> will
> do
>>> but that won't always be the case .. So it's probably worth it to
>>> create
> a
>>> valid enough 'sample' foundation that people can build upon for
>>> their
> own
>>> sites?
>>>
>>> -- Chris
>>>
>>>
>>> On Apr 11, 2008, at 8:25 PM, Brian Eaton wrote:
>>>
>>> On Fri, Apr 11, 2008 at 10:57 AM, Kevin Brown <et...@google.com>
>>> wrote:
>>>>
>>>>> more inputs would need to be provided.
>>>>> javascript/container/sample-metadata
>>>>> wires this up. There's an outstanding ticket to wire the metadata
>>>>> servlet up
>>>>> to the sample pages, but it hasn't happened yet.
>>>>>
>>>>
>>>> OK. I'm not confident I can do that in the way the Shindig team
>>>> would
>>>> like it done, so I'm not going to grab that ticket.
>>>>
>>>> Revised patch that should fix the immediate problem is attached.
>>>> <faketoken.patch>
>>>>
>>>
>>>
>>
>>
>> --
>> ~Kevin
>
>
>
>
> --
> ~Kevin
RE: OAuth broke socialdata interface
Posted by Chris Chabot <ch...@xs4all.nl>.
Well the problem I could see with this (the container creating 'some'
security token), is that other parts of shindig (such as the socialdata
part) will use the standard blob decrypter to decrypt it, and expect a valid
array with viewer / owner / module id / app id / domain information
So take the situation where someone is using the RPC service to create a
iframe url, you would probably do this because your not writing java
servlets right, but would rather use shindig as a 'black box'.
In that scenario you would have no way to generate a security token that
would work with the other parts of shindig (i.a.w. socialdata) , and you
would be forced to write some java code anyhow ... which departs from the
black box concept.
Disclaimer 1: I'm just going by the current java code, where the gadget data
servlet takes the st param, decrypts it using the basic blob crypter logic,
and uses the owner and viewer data from it to generate the isViewer /
isOwner and friend list information.
Disclaimer 2: I'm assuming that the RPC service is still meant to allow
shindig to be used in a 'black box' type scenario, where shindig creates
your iframe url's, renders the gadgets and provides a gateway to an external
social data source. Based on this assumption this scenario -should- work
with a security token that is created, consumed and meaningful inside
shindig.
-- Chris
-----Original Message-----
From: Kevin Brown [mailto:etnu@google.com]
Sent: Saturday, April 12, 2008 21:29
To: shindig-dev@incubator.apache.org
Subject: Re: OAuth broke socialdata interface
Er -- one additional thing. If we *do* allow the metadata servlet to
generate security tokens, we must then layer another protection mechanism on
top of it. I honestly have no idea what would be appropriate here. Normally
you'd use cookies, but that's not really viable here.
With that in mind, having the consuming container generate the security
tokens and attaching them to the metadata-produced iframes is probably still
the best option.
On Sat, Apr 12, 2008 at 12:26 PM, Kevin Brown <et...@google.com> wrote:
> On Sat, Apr 12, 2008 at 3:11 AM, Chris Chabot <ch...@xs4all.nl> wrote:
>
> > What i imagine should happen is that:
> >
> > 1) The PRC service (see RpcServlet and jsonRpcHandler, etc) which
> > generates a iframe url, is modified to include the proper st= security
token
> > in that url. We should be able to tell the the rpc service who our
> > viewer/owner/domain is, is this already in place? (haven't written that
yet
> > on the php side so my knowledge is lacking there)
>
>
> I'm still not sure which way is the right way to go on this one. Putting
> this into the metadata handler would make sense (and the wiring is mostly
> there), but on the other hand I think it might be more natural for the
> metadata handler to return the "raw" url, and allow consumers of the
> metadata handler to append the security token. This makes it much easier
to
> isolate ownership of encryption keys.
>
> Of course, this makes using the metadata handlers directly from client
> side javascript (via XHR) harder. I wonder if many people will actually be
> using this in the "real world" though -- I certainly didn't build it with
> that in mind. I assumed most people would hit the metadata servlet from
> their existing site.
>
> I'm more than happy to support both if there's enough demand from users.
> We'd simply not generate st if the appropriate inputs are missing.
>
> 2) We rewrite the examples / sample container to use this RPC service (see
> > javascript/container and javascript/samplecontainer). We should be able
to
> > tell it the owner, viewer and module id, plus the domain (which we can
> > easily retrieve in javascript in the examples). In the examples this
would
> > be john.doe x2, the incremental module id it generates, and the domain
from
> > the current document; But any container-to-be would just modify this
code
> > and put the (site) authenticated owner and viewer here instead, and be
done
> > with it :)
>
>
> Agreed that this should be done (I could have sworn that I opened a JIRA
> ticket to do this).
>
>
> > This way it should just work out of the box for anyone trying out the
> > examples & sample container, and more importantly, if they use this as a
> > basis of their own container they will actually have a somewhat working
and
> > secure setup that wouldn't allow their users to spoof identities and
'hack'
> > the gadgets.
> >
> > My concern for this was inspired by some of the apache guys at the
> > ApacheCon, who in our meet-up mentioned "With <this other project> we
supply
> > a basic example that people take and build upon and expand to make their
own
> > site", and i think that is how people will probably end up using shindig
too
> > in the long run. Right now it is a pretty 'controller' environment still
and
> > we can afford some basic assumptions about what people should and will
do
> > but that won't always be the case .. So it's probably worth it to create
a
> > valid enough 'sample' foundation that people can build upon for their
own
> > sites?
> >
> > -- Chris
> >
> >
> > On Apr 11, 2008, at 8:25 PM, Brian Eaton wrote:
> >
> > On Fri, Apr 11, 2008 at 10:57 AM, Kevin Brown <et...@google.com> wrote:
> > >
> > > > more inputs would need to be provided.
> > > > javascript/container/sample-metadata
> > > > wires this up. There's an outstanding ticket to wire the metadata
> > > > servlet up
> > > > to the sample pages, but it hasn't happened yet.
> > > >
> > >
> > > OK. I'm not confident I can do that in the way the Shindig team would
> > > like it done, so I'm not going to grab that ticket.
> > >
> > > Revised patch that should fix the immediate problem is attached.
> > > <faketoken.patch>
> > >
> >
> >
>
>
> --
> ~Kevin
--
~Kevin
Re: OAuth broke socialdata interface
Posted by Kevin Brown <et...@google.com>.
Er -- one additional thing. If we *do* allow the metadata servlet to
generate security tokens, we must then layer another protection mechanism on
top of it. I honestly have no idea what would be appropriate here. Normally
you'd use cookies, but that's not really viable here.
With that in mind, having the consuming container generate the security
tokens and attaching them to the metadata-produced iframes is probably still
the best option.
On Sat, Apr 12, 2008 at 12:26 PM, Kevin Brown <et...@google.com> wrote:
> On Sat, Apr 12, 2008 at 3:11 AM, Chris Chabot <ch...@xs4all.nl> wrote:
>
> > What i imagine should happen is that:
> >
> > 1) The PRC service (see RpcServlet and jsonRpcHandler, etc) which
> > generates a iframe url, is modified to include the proper st= security token
> > in that url. We should be able to tell the the rpc service who our
> > viewer/owner/domain is, is this already in place? (haven't written that yet
> > on the php side so my knowledge is lacking there)
>
>
> I'm still not sure which way is the right way to go on this one. Putting
> this into the metadata handler would make sense (and the wiring is mostly
> there), but on the other hand I think it might be more natural for the
> metadata handler to return the "raw" url, and allow consumers of the
> metadata handler to append the security token. This makes it much easier to
> isolate ownership of encryption keys.
>
> Of course, this makes using the metadata handlers directly from client
> side javascript (via XHR) harder. I wonder if many people will actually be
> using this in the "real world" though -- I certainly didn't build it with
> that in mind. I assumed most people would hit the metadata servlet from
> their existing site.
>
> I'm more than happy to support both if there's enough demand from users.
> We'd simply not generate st if the appropriate inputs are missing.
>
> 2) We rewrite the examples / sample container to use this RPC service (see
> > javascript/container and javascript/samplecontainer). We should be able to
> > tell it the owner, viewer and module id, plus the domain (which we can
> > easily retrieve in javascript in the examples). In the examples this would
> > be john.doe x2, the incremental module id it generates, and the domain from
> > the current document; But any container-to-be would just modify this code
> > and put the (site) authenticated owner and viewer here instead, and be done
> > with it :)
>
>
> Agreed that this should be done (I could have sworn that I opened a JIRA
> ticket to do this).
>
>
> > This way it should just work out of the box for anyone trying out the
> > examples & sample container, and more importantly, if they use this as a
> > basis of their own container they will actually have a somewhat working and
> > secure setup that wouldn't allow their users to spoof identities and 'hack'
> > the gadgets.
> >
> > My concern for this was inspired by some of the apache guys at the
> > ApacheCon, who in our meet-up mentioned "With <this other project> we supply
> > a basic example that people take and build upon and expand to make their own
> > site", and i think that is how people will probably end up using shindig too
> > in the long run. Right now it is a pretty 'controller' environment still and
> > we can afford some basic assumptions about what people should and will do
> > but that won't always be the case .. So it's probably worth it to create a
> > valid enough 'sample' foundation that people can build upon for their own
> > sites?
> >
> > -- Chris
> >
> >
> > On Apr 11, 2008, at 8:25 PM, Brian Eaton wrote:
> >
> > On Fri, Apr 11, 2008 at 10:57 AM, Kevin Brown <et...@google.com> wrote:
> > >
> > > > more inputs would need to be provided.
> > > > javascript/container/sample-metadata
> > > > wires this up. There's an outstanding ticket to wire the metadata
> > > > servlet up
> > > > to the sample pages, but it hasn't happened yet.
> > > >
> > >
> > > OK. I'm not confident I can do that in the way the Shindig team would
> > > like it done, so I'm not going to grab that ticket.
> > >
> > > Revised patch that should fix the immediate problem is attached.
> > > <faketoken.patch>
> > >
> >
> >
>
>
> --
> ~Kevin
--
~Kevin
Re: OAuth broke socialdata interface
Posted by Kevin Brown <et...@google.com>.
On Sat, Apr 12, 2008 at 3:11 AM, Chris Chabot <ch...@xs4all.nl> wrote:
> What i imagine should happen is that:
>
> 1) The PRC service (see RpcServlet and jsonRpcHandler, etc) which
> generates a iframe url, is modified to include the proper st= security token
> in that url. We should be able to tell the the rpc service who our
> viewer/owner/domain is, is this already in place? (haven't written that yet
> on the php side so my knowledge is lacking there)
I'm still not sure which way is the right way to go on this one. Putting
this into the metadata handler would make sense (and the wiring is mostly
there), but on the other hand I think it might be more natural for the
metadata handler to return the "raw" url, and allow consumers of the
metadata handler to append the security token. This makes it much easier to
isolate ownership of encryption keys.
Of course, this makes using the metadata handlers directly from client side
javascript (via XHR) harder. I wonder if many people will actually be using
this in the "real world" though -- I certainly didn't build it with that in
mind. I assumed most people would hit the metadata servlet from their
existing site.
I'm more than happy to support both if there's enough demand from users.
We'd simply not generate st if the appropriate inputs are missing.
2) We rewrite the examples / sample container to use this RPC service (see
> javascript/container and javascript/samplecontainer). We should be able to
> tell it the owner, viewer and module id, plus the domain (which we can
> easily retrieve in javascript in the examples). In the examples this would
> be john.doe x2, the incremental module id it generates, and the domain from
> the current document; But any container-to-be would just modify this code
> and put the (site) authenticated owner and viewer here instead, and be done
> with it :)
Agreed that this should be done (I could have sworn that I opened a JIRA
ticket to do this).
> This way it should just work out of the box for anyone trying out the
> examples & sample container, and more importantly, if they use this as a
> basis of their own container they will actually have a somewhat working and
> secure setup that wouldn't allow their users to spoof identities and 'hack'
> the gadgets.
>
> My concern for this was inspired by some of the apache guys at the
> ApacheCon, who in our meet-up mentioned "With <this other project> we supply
> a basic example that people take and build upon and expand to make their own
> site", and i think that is how people will probably end up using shindig too
> in the long run. Right now it is a pretty 'controller' environment still and
> we can afford some basic assumptions about what people should and will do
> but that won't always be the case .. So it's probably worth it to create a
> valid enough 'sample' foundation that people can build upon for their own
> sites?
>
> -- Chris
>
>
> On Apr 11, 2008, at 8:25 PM, Brian Eaton wrote:
>
> On Fri, Apr 11, 2008 at 10:57 AM, Kevin Brown <et...@google.com> wrote:
> >
> > > more inputs would need to be provided.
> > > javascript/container/sample-metadata
> > > wires this up. There's an outstanding ticket to wire the metadata
> > > servlet up
> > > to the sample pages, but it hasn't happened yet.
> > >
> >
> > OK. I'm not confident I can do that in the way the Shindig team would
> > like it done, so I'm not going to grab that ticket.
> >
> > Revised patch that should fix the immediate problem is attached.
> > <faketoken.patch>
> >
>
>
--
~Kevin
Re: OAuth broke socialdata interface
Posted by Chris Chabot <ch...@xs4all.nl>.
What i imagine should happen is that:
1) The PRC service (see RpcServlet and jsonRpcHandler, etc) which
generates a iframe url, is modified to include the proper st= security
token in that url. We should be able to tell the the rpc service who
our viewer/owner/domain is, is this already in place? (haven't written
that yet on the php side so my knowledge is lacking there)
2) We rewrite the examples / sample container to use this RPC service
(see javascript/container and javascript/samplecontainer). We should
be able to tell it the owner, viewer and module id, plus the domain
(which we can easily retrieve in javascript in the examples). In the
examples this would be john.doe x2, the incremental module id it
generates, and the domain from the current document; But any container-
to-be would just modify this code and put the (site) authenticated
owner and viewer here instead, and be done with it :)
This way it should just work out of the box for anyone trying out the
examples & sample container, and more importantly, if they use this as
a basis of their own container they will actually have a somewhat
working and secure setup that wouldn't allow their users to spoof
identities and 'hack' the gadgets.
My concern for this was inspired by some of the apache guys at the
ApacheCon, who in our meet-up mentioned "With <this other project> we
supply a basic example that people take and build upon and expand to
make their own site", and i think that is how people will probably end
up using shindig too in the long run. Right now it is a pretty
'controller' environment still and we can afford some basic
assumptions about what people should and will do but that won't always
be the case .. So it's probably worth it to create a valid enough
'sample' foundation that people can build upon for their own sites?
-- Chris
On Apr 11, 2008, at 8:25 PM, Brian Eaton wrote:
> On Fri, Apr 11, 2008 at 10:57 AM, Kevin Brown <et...@google.com> wrote:
>> more inputs would need to be provided. javascript/container/sample-
>> metadata
>> wires this up. There's an outstanding ticket to wire the metadata
>> servlet up
>> to the sample pages, but it hasn't happened yet.
>
> OK. I'm not confident I can do that in the way the Shindig team would
> like it done, so I'm not going to grab that ticket.
>
> Revised patch that should fix the immediate problem is attached.
> <faketoken.patch>
Re: OAuth broke socialdata interface
Posted by Brian Eaton <be...@google.com>.
On Fri, Apr 11, 2008 at 10:57 AM, Kevin Brown <et...@google.com> wrote:
> more inputs would need to be provided. javascript/container/sample-metadata
> wires this up. There's an outstanding ticket to wire the metadata servlet up
> to the sample pages, but it hasn't happened yet.
OK. I'm not confident I can do that in the way the Shindig team would
like it done, so I'm not going to grab that ticket.
Revised patch that should fix the immediate problem is attached.
Re: OAuth broke socialdata interface
Posted by Kevin Brown <et...@google.com>.
On Fri, Apr 11, 2008 at 10:48 AM, Brian Eaton <be...@google.com> wrote:
> On Fri, Apr 11, 2008 at 10:39 AM, Kevin Brown <et...@google.com> wrote:
> > Security tokens should be generated by the gadget metadata servlet. More
> > than socialdata needs to consume that token.
>
> Where does that servlet live, and where is the js that can hook into
> the servlet?
gadgets/http/RpcServlet
more inputs would need to be provided. javascript/container/sample-metadata
wires this up. There's an outstanding ticket to wire the metadata servlet up
to the sample pages, but it hasn't happened yet.
> That's fine too. I suggested alternatives because you mentioned that
> you wanted a decent default implementation of the gadget security
> token. We can build one on top of BlobCrypter pretty easily, I just
> don't have a clue where to hook it up.
>
I think we need a default that people could use "for real", but the dummy
one is pretty useful for the sample container stuff.
--
~Kevin
Re: OAuth broke socialdata interface
Posted by Brian Eaton <be...@google.com>.
On Fri, Apr 11, 2008 at 10:39 AM, Kevin Brown <et...@google.com> wrote:
> Security tokens should be generated by the gadget metadata servlet. More
> than socialdata needs to consume that token.
Where does that servlet live, and where is the js that can hook into
the servlet?
> Again, though -- why not just use the dummy tokens by default? At least
> until we have a real default implementation of the certs...
That's fine too. I suggested alternatives because you mentioned that
you wanted a decent default implementation of the gadget security
token. We can build one on top of BlobCrypter pretty easily, I just
don't have a clue where to hook it up.
Re: OAuth broke socialdata interface
Posted by Kevin Brown <et...@google.com>.
Security tokens should be generated by the gadget metadata servlet. More
than socialdata needs to consume that token.
Again, though -- why not just use the dummy tokens by default? At least
until we have a real default implementation of the certs...
On Thu, Apr 10, 2008 at 11:14 PM, Brian Eaton <be...@google.com> wrote:
> OK, patch attached.
>
> Maybe we should update the sample socialdata servlets so they can
> return a security token for the gadget when the gadget renders? I'm
> not sure where that servlet would hook in, but if someone tells me
> where it should go (on the server) and where it should be called from
> (on the sample container pages), the actual code is pretty simple.
>
> Or maybe that's not what the sample servlets are for. I don't really
> know.
>
> Cheers,
> Brian
>
> On Thu, Apr 10, 2008 at 3:26 PM, Kevin Brown <et...@google.com> wrote:
> > The BasicTokenDecoder interface is actually incredibly lame, so a static
> > token would be possible. The format is something like app id : owner id
> :
> > viewer id : domain. This was done intentionally for this sort of
> testing. We
> > probably need to update the sample page for this.
> >
> >
> >
> > On Thu, Apr 10, 2008 at 2:52 PM, Chris Chabot <ch...@xs4all.nl>
> wrote:
> >
> > > Hey Guys,
> > >
> > > I've noticed that the recent OAuth patches broke the social data part
> of
> > > shindig in the sample container situation.
> > >
> > > When i run the
> > >
> http://opensocial-resources.googlecode.com/svn/tests/trunk/compliancetests.xmlin
> > > it, i get an error on the console (included @ the bottom of the mail)
> > > because of the empty security token (st in the post) in those social
> data
> > > requests makes it quite upset :)
> > >
> > > Now i guess the best way to fix this is by actually have a valid
> security
> > > token, but in static html sample files that might be tricky
> > >
> > > Maybe we can hook them up to the RPC service of shindig and have it
> > > generate a valid security token? I quickly ran this idea by Cassie at
> the
> > > apache con yesterday and her response was along the lines of "Yes
> that seems
> > > the best way to fix it ... who ever broke it should do that", so i
> guess
> > > that would be you Brian? :)
> > >
> > > That leaves me with the question what i would have to do to make that
> work
> > > with the PHP version too, haven't started on the OAuth part yet (been
> > > working hard on the social data part of things), anyone have an
> overview for
> > > me what the minimal thing is i need to create to make it work,
> preferable in
> > > a wire format compatible way so that components of the java and php
> land can
> > > still be used side by side?
> > >
> > >
> > > Reproducing this is simple ... hook up the compliancetests.xml in
> > > sampe1.html for instance, and inspect at the json replies in firebug
> > >
> > > The Backtrace on the console:
> > >
> > > 2008-04-10 23:40:33.973::WARN: /gadgets/socialdata
> > > java.lang.ArrayIndexOutOfBoundsException: 1
> > > at
> > >
> org.apache.shindig.gadgets.BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:47)
> > > at
> > >
> org.apache.shindig.social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
> > > at
> > >
> org.apache.shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:80)
> > > at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> > > at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> > > at
> > >
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> > > at
> > >
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
> > > at
> > >
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> > > at
> > >
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> > > at
> > >
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
> > > at
> > > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> > > at
> > >
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> > > at
> > >
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> > > at
> > >
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> > > at org.mortbay.jetty.Server.handle(Server.java:324)
> > > at
> > >
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> > > at
> > >
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
> > > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
> > > at
> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> > > at
> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> > > at
> > >
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> > > at
> > >
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
> > >
> > > The html page in the json reply (which btw is a bug on its self too,
> this
> > > should be a nice json error and not a html backtrace rigtht? :P) is
> much the
> > > same:
> > >
> > > <html>
> > > <head>
> > > <meta http-equiv="Content-Type" content="text/html;
> charset=ISO-8859-1"/>
> > > <title>Error 500 1</title>
> > > </head>
> > > <body><h2>HTTP ERROR: 500</h2><pre>1</pre>
> > > <p>RequestURI=/gadgets/socialdata</p><h3>Caused
> > > by:</h3><pre>java.lang.ArrayIndexOutOfBoundsException
> > > : 1
> > > at
> > >
> org.apache.shindig.gadgets.BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:47)
> > > at
> > >
> org.apache.shindig.social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
> > > at
> > >
> org.apache.shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:80)
> > > at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> > > at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> > > at
> > >
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> > > at
> > >
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
> > > at
> > >
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> > > at
> > >
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> > > at
> > >
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
> > > at
> > > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> > > at
> > >
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> > > at
> > >
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> > > at
> > >
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> > > at org.mortbay.jetty.Server.handle(Server.java:324)
> > > at
> > >
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> > > at
> > >
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
> > > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
> > > at
> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> > > at
> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> > > at
> > >
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> > > at
> > >
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
> > > </pre>
> > > <p><i><small><a href="http://jetty.mortbay.org/">Powered by
> > > Jetty://</a></small></i></p><br/>
> > >
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > <br/>
> > > </body>
> > > </html>
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
>
--
~Kevin
Re: OAuth broke socialdata interface
Posted by Brian Eaton <be...@google.com>.
OK, patch attached.
Maybe we should update the sample socialdata servlets so they can
return a security token for the gadget when the gadget renders? I'm
not sure where that servlet would hook in, but if someone tells me
where it should go (on the server) and where it should be called from
(on the sample container pages), the actual code is pretty simple.
Or maybe that's not what the sample servlets are for. I don't really know.
Cheers,
Brian
On Thu, Apr 10, 2008 at 3:26 PM, Kevin Brown <et...@google.com> wrote:
> The BasicTokenDecoder interface is actually incredibly lame, so a static
> token would be possible. The format is something like app id : owner id :
> viewer id : domain. This was done intentionally for this sort of testing. We
> probably need to update the sample page for this.
>
>
>
> On Thu, Apr 10, 2008 at 2:52 PM, Chris Chabot <ch...@xs4all.nl> wrote:
>
> > Hey Guys,
> >
> > I've noticed that the recent OAuth patches broke the social data part of
> > shindig in the sample container situation.
> >
> > When i run the
> > http://opensocial-resources.googlecode.com/svn/tests/trunk/compliancetests.xml in
> > it, i get an error on the console (included @ the bottom of the mail)
> > because of the empty security token (st in the post) in those social data
> > requests makes it quite upset :)
> >
> > Now i guess the best way to fix this is by actually have a valid security
> > token, but in static html sample files that might be tricky
> >
> > Maybe we can hook them up to the RPC service of shindig and have it
> > generate a valid security token? I quickly ran this idea by Cassie at the
> > apache con yesterday and her response was along the lines of "Yes that seems
> > the best way to fix it ... who ever broke it should do that", so i guess
> > that would be you Brian? :)
> >
> > That leaves me with the question what i would have to do to make that work
> > with the PHP version too, haven't started on the OAuth part yet (been
> > working hard on the social data part of things), anyone have an overview for
> > me what the minimal thing is i need to create to make it work, preferable in
> > a wire format compatible way so that components of the java and php land can
> > still be used side by side?
> >
> >
> > Reproducing this is simple ... hook up the compliancetests.xml in
> > sampe1.html for instance, and inspect at the json replies in firebug
> >
> > The Backtrace on the console:
> >
> > 2008-04-10 23:40:33.973::WARN: /gadgets/socialdata
> > java.lang.ArrayIndexOutOfBoundsException: 1
> > at
> > org.apache.shindig.gadgets.BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:47)
> > at
> > org.apache.shindig.social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
> > at
> > org.apache.shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:80)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> > at
> > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> > at
> > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
> > at
> > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> > at
> > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> > at
> > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
> > at
> > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> > at
> > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> > at
> > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> > at
> > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> > at org.mortbay.jetty.Server.handle(Server.java:324)
> > at
> > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> > at
> > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
> > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
> > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> > at
> > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> > at
> > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
> >
> > The html page in the json reply (which btw is a bug on its self too, this
> > should be a nice json error and not a html backtrace rigtht? :P) is much the
> > same:
> >
> > <html>
> > <head>
> > <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
> > <title>Error 500 1</title>
> > </head>
> > <body><h2>HTTP ERROR: 500</h2><pre>1</pre>
> > <p>RequestURI=/gadgets/socialdata</p><h3>Caused
> > by:</h3><pre>java.lang.ArrayIndexOutOfBoundsException
> > : 1
> > at
> > org.apache.shindig.gadgets.BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:47)
> > at
> > org.apache.shindig.social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
> > at
> > org.apache.shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:80)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> > at
> > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> > at
> > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
> > at
> > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> > at
> > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> > at
> > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
> > at
> > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> > at
> > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> > at
> > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> > at
> > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> > at org.mortbay.jetty.Server.handle(Server.java:324)
> > at
> > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> > at
> > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
> > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
> > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> > at
> > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> > at
> > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
> > </pre>
> > <p><i><small><a href="http://jetty.mortbay.org/">Powered by
> > Jetty://</a></small></i></p><br/>
> >
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > <br/>
> > </body>
> > </html>
> >
>
>
>
> --
> ~Kevin
>
Re: OAuth broke socialdata interface
Posted by Kevin Brown <et...@google.com>.
The BasicTokenDecoder interface is actually incredibly lame, so a static
token would be possible. The format is something like app id : owner id :
viewer id : domain. This was done intentionally for this sort of testing. We
probably need to update the sample page for this.
On Thu, Apr 10, 2008 at 2:52 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> Hey Guys,
>
> I've noticed that the recent OAuth patches broke the social data part of
> shindig in the sample container situation.
>
> When i run the
> http://opensocial-resources.googlecode.com/svn/tests/trunk/compliancetests.xml in
> it, i get an error on the console (included @ the bottom of the mail)
> because of the empty security token (st in the post) in those social data
> requests makes it quite upset :)
>
> Now i guess the best way to fix this is by actually have a valid security
> token, but in static html sample files that might be tricky
>
> Maybe we can hook them up to the RPC service of shindig and have it
> generate a valid security token? I quickly ran this idea by Cassie at the
> apache con yesterday and her response was along the lines of "Yes that seems
> the best way to fix it ... who ever broke it should do that", so i guess
> that would be you Brian? :)
>
> That leaves me with the question what i would have to do to make that work
> with the PHP version too, haven't started on the OAuth part yet (been
> working hard on the social data part of things), anyone have an overview for
> me what the minimal thing is i need to create to make it work, preferable in
> a wire format compatible way so that components of the java and php land can
> still be used side by side?
>
>
> Reproducing this is simple ... hook up the compliancetests.xml in
> sampe1.html for instance, and inspect at the json replies in firebug
>
> The Backtrace on the console:
>
> 2008-04-10 23:40:33.973::WARN: /gadgets/socialdata
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.shindig.gadgets.BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:47)
> at
> org.apache.shindig.social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
> at
> org.apache.shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:80)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:324)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
>
> The html page in the json reply (which btw is a bug on its self too, this
> should be a nice json error and not a html backtrace rigtht? :P) is much the
> same:
>
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
> <title>Error 500 1</title>
> </head>
> <body><h2>HTTP ERROR: 500</h2><pre>1</pre>
> <p>RequestURI=/gadgets/socialdata</p><h3>Caused
> by:</h3><pre>java.lang.ArrayIndexOutOfBoundsException
> : 1
> at
> org.apache.shindig.gadgets.BasicGadgetTokenDecoder.createToken(BasicGadgetTokenDecoder.java:47)
> at
> org.apache.shindig.social.GadgetDataServlet.createResponse(GadgetDataServlet.java:97)
> at
> org.apache.shindig.social.GadgetDataServlet.doPost(GadgetDataServlet.java:80)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:206)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:324)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
> </pre>
> <p><i><small><a href="http://jetty.mortbay.org/">Powered by
> Jetty://</a></small></i></p><br/>
>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> <br/>
> </body>
> </html>
>
--
~Kevin