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:[EMAIL PROTECTED]
Sent: Saturday, April 12, 2008 21:29
To: [email protected]
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 <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 12, 2008 at 3:11 AM, Chris Chabot <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
