You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Raymond Auge <ra...@liferay.com> on 2008/04/14 23:43:14 UTC
syndicator, domain...
These therms are used interchangeably in the code... can you choose 1 or
the other? It simply causes confusion.
Also, what is appId supposed to be, exactly? What is the definition? Is
it simply a unique identifier of the current gadget?
If so, why not simply use the URL? This must be unique already...
If there are other reasons for making this not simply the URL, perhaps a
good way of gen'ing an appId is by using an MD5, or SHA-1 hash.
There is a javascript version of both here
http://pajhome.org.uk/crypt/md5/ (BSD License)
They seem very fast.
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
Re: syndicator, domain...
Posted by Kevin Brown <et...@google.com>.
On Mon, Apr 14, 2008 at 2:43 PM, Raymond Auge <ra...@liferay.com> wrote:
> These therms are used interchangeably in the code... can you choose 1 or
> the other? It simply causes confusion.
syndicator is synonymous with container. There's an open ticket to eliminate
the "syndicator" terminology.
Domain may or may not mean the same thing as container, but it usually does.
> Also, what is appId supposed to be, exactly? What is the definition? Is
> it simply a unique identifier of the current gadget?
>
> If so, why not simply use the URL? This must be unique already...
Open spec discussion issue, actually -- You can find relevant links at
http://opensocial.org. I don't want to rehash the entire discussion here,
but your thinking is pretty much exactly what many of us have concluded
already.
--
~Kevin
Re: syndicator, domain...
Posted by Brian Eaton <be...@google.com>.
On Mon, Apr 14, 2008 at 3:05 PM, Raymond Auge <ra...@liferay.com> wrote:
> On Mon, 2008-04-14 at 14:47 -0700, Brian Eaton wrote:
>
> > You can't trust javascript to specify the app id, it has to come from
> > the gadget server (and be signed with the gadget server's private key)
> > in order to be trusted.
>
> In this statement... is "gadget server" really "gadget container" as I
> would imagine that the gadget "server" might be some remote site
> providing the "application's" blob... where the "gadget container" is
> the one providing the runtime environment. I'd imagine that the
> "container" is the one responsible for providing the signed token... not
> the gadget "server"?
I'm going to ignore all terminology for a minute, because it makes my
head hurt. Yeah, your understanding is correct. The thingy creating
links to Shindig's /gadget/ifr endpoint needs to include a security
token on the URL fragment when it creates the link. The javascript
inserted by Shindig when it renders the gadget should snarf the
security token off the fragment, and include it in makeRequest
messages passed to Shindig. When Shindig sees a makeRequest message
with a request for signing, it should decode/verify the security
token, then include some bits of information about the
owner/viewer/appid when it forwards the request to whatever server the
gadget wants to talk to.
> Can we have a sample of a signed token render, even if it's not fully
> implemented in code... even just in a README??? Or is this still
> premature?
You can build one on top of BlobCrypter pretty easily. There's been
talk about hooking up the sample container to BlobCrypter so that
there's an easy demo, so far no one has grabbed that work.
Cheers,
Brian
Re: syndicator, domain...
Posted by Kevin Brown <et...@google.com>.
On Mon, Apr 14, 2008 at 3:05 PM, Raymond Auge <ra...@liferay.com> wrote:
> Ok, wow... great response x3... next question.
>
> On Mon, 2008-04-14 at 14:47 -0700, Brian Eaton wrote:
>
> > You can't trust javascript to specify the app id, it has to come from
> > the gadget server (and be signed with the gadget server's private key)
> > in order to be trusted.
>
> In this statement... is "gadget server" really "gadget container" as I
> would imagine that the gadget "server" might be some remote site
> providing the "application's" blob... where the "gadget container" is
> the one providing the runtime environment. I'd imagine that the
> "container" is the one responsible for providing the signed token... not
> the gadget "server"?
The container (never "gadget container") would refer to the specific site
that renders opensocial gadgets (MySpace, Orkut, hi5, etc.)
The "gadget server" refers to the server that renders the gadget --
essentially the parts provided by org.apache.shindig.gadgets within the
Shindig project.
The thing that actually serves the gadget xml (and possibly handles proxied
callbacks and such) is usually just referred to as the "gadget" (sometimes
as the "service provider").
--
~Kevin
Re: syndicator, domain...
Posted by Raymond Auge <ra...@liferay.com>.
Ok, wow... great response x3... next question.
On Mon, 2008-04-14 at 14:47 -0700, Brian Eaton wrote:
> You can't trust javascript to specify the app id, it has to come from
> the gadget server (and be signed with the gadget server's private key)
> in order to be trusted.
In this statement... is "gadget server" really "gadget container" as I
would imagine that the gadget "server" might be some remote site
providing the "application's" blob... where the "gadget container" is
the one providing the runtime environment. I'd imagine that the
"container" is the one responsible for providing the signed token... not
the gadget "server"?
Can we have a sample of a signed token render, even if it's not fully
implemented in code... even just in a README??? Or is this still
premature?
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
Re: syndicator, domain...
Posted by Brian Eaton <be...@google.com>.
On Mon, Apr 14, 2008 at 2:43 PM, Raymond Auge <ra...@liferay.com> wrote:
> Also, what is appId supposed to be, exactly? What is the definition? Is
> it simply a unique identifier of the current gadget?
It identifies a given gadget. appid@container should be globally
unique, I think.
> If so, why not simply use the URL? This must be unique already...
+1. There's a proposal on the spec mailing list to do this. The
implementation is a little tricky, because you don't want to explode
the size of the security token by embedding the entire gadget URL in
there, but it's surely doable.
> If there are other reasons for making this not simply the URL, perhaps a
> good way of gen'ing an appId is by using an MD5, or SHA-1 hash.
We could do this too. I'm not wild about the idea because it's a
little obscure and doesn't save that much in terms of the size.
> There is a javascript version of both here
> http://pajhome.org.uk/crypt/md5/ (BSD License)
You can't trust javascript to specify the app id, it has to come from
the gadget server (and be signed with the gadget server's private key)
in order to be trusted. Check out SigningFetcher.java to see what I'm
talking about.
Cheers,
Brian
Re: syndicator, domain...
Posted by Santiago Gala <sa...@gmail.com>.
El lun, 14-04-2008 a las 17:43 -0400, Raymond Auge escribió:
> These therms are used interchangeably in the code... can you choose 1 or
> the other? It simply causes confusion.
I have a patch readying to be applied, as per
https://issues.apache.org/jira/browse/SHINDIG-146 , to rename syndicator
-> container. I have not checked for domain term. Basically the code in
http://github.com/sgala/apache-incubator-shindig/commits/synd-rename-2
that is not in current svn is what should get committed to "clean" the
use of syndicator off the codebase.
I'll let Kevin or somebody else more fluent on the terminology to
clarify the rest.
Regards
Santiago
>
> Also, what is appId supposed to be, exactly? What is the definition? Is
> it simply a unique identifier of the current gadget?
>
> If so, why not simply use the URL? This must be unique already...
>
> If there are other reasons for making this not simply the URL, perhaps a
> good way of gen'ing an appId is by using an MD5, or SHA-1 hash.
>
> There is a javascript version of both here
> http://pajhome.org.uk/crypt/md5/ (BSD License)
>
> They seem very fast.
>
> Raymond Augé
> Software Engineer
> Liferay, Inc.
> Enterprise. Open Source. For Life.
--
Santiago Gala
http://memojo.com/~sgala/blog/