You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Louis Ryan <lr...@google.com> on 2008/05/02 04:15:11 UTC
Re: Proposal : Modify gadget spec to allow for authenticated/signed preloads & allow preloads to be defined per Content section.
I'd like to propose some amendments to this spec, possibly for 0.8 if people
are willing but if not at least for experimental inclusion in Shindig in
short-order.
1. Add support for a 'view' attribute which identifies when a Preload should
be executed based on which content sections are rendered. This is to allow
for different preloads on different views. The value of the attribute is a
comma-separated list of views. If the attributes is omitted the preload is
always executed
2. Add support for a new authentication mode. SIGNED_OWNER_ONLY. In this
situation the viewer information is omitted from the signed request. This is
useful when the information returned by the backend does not care about the
viewer. A concrete example is a profile view which is non-interactive but
shows content that is entirely contextual to the owner. Omitting the viewer
from requests for this kind of information allows for significantly better
caching throughout the stack Containers which do not implement this mode can
fallback to SIGNED.
Thoughts?
-Louis
On Thu, Apr 24, 2008 at 8:44 AM, Cassie <do...@google.com> wrote:
> +1
>
> Okay, so Louis, Brian Eaton, Reinoudm and I are +1s and I think Kevin is a
> +1.
> As long as there aren't any objections this will go into 0.8
>
> - Cassie
>
>
>
>
> On Mon, Apr 21, 2008 at 11:46 PM, Kevin Brown <et...@google.com> wrote:
>
> > On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <be...@google.com> wrote:
> >
> > >
> > > So long as we're clear in the spec about what is supposed to happen if
> > > a preload is done for GET http://something, and then the gadget does
> > > POST http://something instead. Those are different requests, a
> > > preload for one should not impact the other.
> >
> >
> > Just changing the verb is one thing, but actually attaching a post body
> > here seems really bizarre.
> >
> >
> > >
> > > Doing preloads only for GET requests sounds reasonable.
> > >
> > > On Mon, Apr 21, 2008 at 9:58 AM, Louis Ryan <lr...@google.com> wrote:
> > > > For the moment just authz, if people have strong feelings about
> > > method,
> > > > post-body etc Im fine to adjust.
> > > >
> > > >
> > > >
> > > > On Mon, Apr 21, 2008 at 7:41 AM, Brian Eaton <be...@google.com>
> > > wrote:
> > > >
> > > > >
> > > > > I read the proposal differently. Any parameter that can be passed
> > > to
> > > > > makeRequest (HTTP, method, post body, etc...) should be an
> > > optional
> > > > > attribute for Preload as well. Or is that not what Louis was
> > > trying
> > > > > to say?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 21, 2008 at 4:33 AM, Cassie <do...@google.com> wrote:
> > > > > > So, to be clear, the only spec change here is to add the "authz"
> > > > attribute
> > > > > > to the "Preload" element, which would be interpreted as Louis
> > > described
> > > > > > above.
> > > > > >
> > > > > > Thanks.
> > > > > > - Cassie
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 15, 2008 at 12:56 PM, Kevin Brown <et...@google.com>
> > > wrote:
> > > > > > >
> > > > > > > On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst <
> > > reinoud@hyves.nl>
> > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > + 1 on the theoretical side, especially since containers
> > > don't have
> > > > to
> > > > > > support the preload (and everything will still work, although
> > > with some
> > > > more
> > > > > > latency)
> > > > > > > >
> > > > > > > > On the practical side: I don't think that the st is sent to
> > > shindig
> > > > at
> > > > > > the moment, so preloading a signed request may be difficult. We
> > > > shouldn't
> > > > > > confuse spec with practical implementation though.
> > > > > > >
> > > > > > >
> > > > > > > This is an implementation detail that is easily remedied. The
> > > security
> > > > > > token solution used by shindig is similar, if not identical, to
> > > that
> > > > used by
> > > > > > other implementations, but it still remains just an
> > > implementation
> > > > detail.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Something else: Can we assume that all preloaded content at
> > > least
> > > > allow
> > > > > > caching during the lifetime of that single gadget instance? It
> > > wouldn't
> > > > make
> > > > > > much sense to preload something that has a no-cache directive...
> > > > > > >
> > > > > > >
> > > > > > > I don't see that as being incompatible. Preloading something
> > > that
> > > > isn't
> > > > > > cacheable just means that I have to take care to refetch it
> > > every gadget
> > > > > > render. Not ideal, certainly, but if the gadget author would be
> > > doing a
> > > > > > makeRequest anyway, it's a lot better to incur that latency
> > > during the
> > > > > > preload in most cases than it is to incur it after the gadget
> > > has been
> > > > > > rendered.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Apr 15, 2008 at 2:38 AM, Kevin Brown <
> > > etnu@google.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden <
> > > bruno@google.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > There's some redundancy here because both the Preload
> > > and the
> > > > > > io.makeRequest have to specify a signed fetch. Is there any way
> > > to avoid
> > > > > > this redundancy? Along those lines, what happens if the Preload
> > > is
> > > > signed
> > > > > > but not the makeRequest? An author could easily try to do a
> > > preload and
> > > > yet
> > > > > > have it fail for simple reasons.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > <Preload href="http://www.myhost.com/getdata"
> > > authz="signed" />
> > > > > > > > > >
> > > > > > > > > > The content of a Preload request is made available to
> > > the gadget
> > > > > > developer by making the equivalent gadgets.io.makeRequest call
> > > on the
> > > > > > browser without making a remote call. E.g.
> > > > > > > > > >
> > > > > > > > > > var params = {}; // forgot "SIGNED" param
> > > > > > > > > >
> > > > > > > > > > gadgets.io.makeRequest("http://www.myhost.com/getdata",
> > > > callback,
> > > > > > params);
> > > > > > > > > >
> > > > > > > > > > Is this makeRequest preloaded or not?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > <Preload> is already in the spec (and tied to makeRequest)
> > > -- the
> > > > only
> > > > > > change Louis is proposing is allowing authentication (something
> > > which
> > > > has
> > > > > > been shown to be necessary by most containers). This
> > > functionality is
> > > > purely
> > > > > > an optimization.
> > > > > > > > >
> > > > > > > > > The need for redundancy is ugly, but I don't see any other
> > > way to
> > > > do
> > > > > > it without making backwards compatibility very difficult. Under
> > > Louis
> > > > > > proposed model, a gadget server that didn't support <Preload>
> > > would
> > > > still
> > > > > > work with the gadget, which seems like a pretty big advantage to
> > > me,
> > > > though
> > > > > > we would probably want to be explicit and require that the authz
> > > used
> > > > > > between <Preload> and makeRequest be identical.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > ~Kevin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ~Kevin
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
> >
> > --
> > ~Kevin
> >
> >
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: Proposal : Modify gadget spec to allow for authenticated/signed preloads & allow preloads to be defined per Content section.
Posted by Kevin Brown <et...@google.com>.
On Thu, May 1, 2008 at 9:18 PM, Louis Ryan <lr...@google.com> wrote:
> Perhaps not.
>
> If the container is not exposing viewer information to the gadget under
> its ACLing rules SIGNED may already not include viewer. It seems
> SIGNED_OWNER just makes this explicit. Not sure how to interpret SIGNED
> &user=viewer when viewer isnt accessible?
I suppose -- adding a new auth type is probably easier. Is there any
significant demand for viewer-only data at this point? I was hoping to avoid
SIGNED, SIGNED_OWNER, and SIGNED_VIEWER.
>
>
>
> On Thu, May 1, 2008 at 7:56 PM, Kevin Brown <et...@google.com> wrote:
>
> > On Thu, May 1, 2008 at 7:15 PM, Louis Ryan <lr...@google.com> wrote:
> >
> > > I'd like to propose some amendments to this spec, possibly for 0.8 if
> > > people are willing but if not at least for experimental inclusion in Shindig
> > > in short-order.
> > >
> > > 1. Add support for a 'view' attribute which identifies when a Preload
> > > should be executed based on which content sections are rendered. This is to
> > > allow for different preloads on different views. The value of the attribute
> > > is a comma-separated list of views. If the attributes is omitted the preload
> > > is always executed
> > >
> > > 2. Add support for a new authentication mode. SIGNED_OWNER_ONLY. In
> > > this situation the viewer information is omitted from the signed request.
> > > This is useful when the information returned by the backend does not care
> > > about the viewer. A concrete example is a profile view which is
> > > non-interactive but shows content that is entirely contextual to the owner.
> > > Omitting the viewer from requests for this kind of information allows for
> > > significantly better caching throughout the stack Containers which do not
> > > implement this mode can fallback to SIGNED.
> >
> >
> > Is a new auth mode really the right thing here? Why not authz="signed"
> > user="(owner | viewer | both)".
> >
> > >
> > >
> > > Thoughts?
> > >
> > > -Louis
> > >
> > >
> > >
> > >
> > > On Thu, Apr 24, 2008 at 8:44 AM, Cassie <do...@google.com> wrote:
> > >
> > > > +1
> > > >
> > > > Okay, so Louis, Brian Eaton, Reinoudm and I are +1s and I think
> > > > Kevin is a +1.
> > > > As long as there aren't any objections this will go into 0.8
> > > >
> > > > - Cassie
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Apr 21, 2008 at 11:46 PM, Kevin Brown <et...@google.com>
> > > > wrote:
> > > >
> > > > > On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <be...@google.com>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > So long as we're clear in the spec about what is supposed to
> > > > > > happen if
> > > > > > a preload is done for GET http://something, and then the gadget
> > > > > > does
> > > > > > POST http://something instead. Those are different requests, a
> > > > > > preload for one should not impact the other.
> > > > >
> > > > >
> > > > > Just changing the verb is one thing, but actually attaching a post
> > > > > body here seems really bizarre.
> > > > >
> > > > >
> > > > > >
> > > > > > Doing preloads only for GET requests sounds reasonable.
> > > > > >
> > > > > > On Mon, Apr 21, 2008 at 9:58 AM, Louis Ryan <lr...@google.com>
> > > > > > wrote:
> > > > > > > For the moment just authz, if people have strong feelings
> > > > > > about method,
> > > > > > > post-body etc Im fine to adjust.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Apr 21, 2008 at 7:41 AM, Brian Eaton <
> > > > > > beaton@google.com> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > I read the proposal differently. Any parameter that can be
> > > > > > passed to
> > > > > > > > makeRequest (HTTP, method, post body, etc...) should be an
> > > > > > optional
> > > > > > > > attribute for Preload as well. Or is that not what Louis
> > > > > > was trying
> > > > > > > > to say?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Apr 21, 2008 at 4:33 AM, Cassie <do...@google.com>
> > > > > > wrote:
> > > > > > > > > So, to be clear, the only spec change here is to add the
> > > > > > "authz"
> > > > > > > attribute
> > > > > > > > > to the "Preload" element, which would be interpreted as
> > > > > > Louis described
> > > > > > > > > above.
> > > > > > > > >
> > > > > > > > > Thanks.
> > > > > > > > > - Cassie
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Apr 15, 2008 at 12:56 PM, Kevin Brown <
> > > > > > etnu@google.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst <
> > > > > > reinoud@hyves.nl>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > + 1 on the theoretical side, especially since
> > > > > > containers don't have
> > > > > > > to
> > > > > > > > > support the preload (and everything will still work,
> > > > > > although with some
> > > > > > > more
> > > > > > > > > latency)
> > > > > > > > > > >
> > > > > > > > > > > On the practical side: I don't think that the st is
> > > > > > sent to shindig
> > > > > > > at
> > > > > > > > > the moment, so preloading a signed request may be
> > > > > > difficult. We
> > > > > > > shouldn't
> > > > > > > > > confuse spec with practical implementation though.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > This is an implementation detail that is easily
> > > > > > remedied. The security
> > > > > > > > > token solution used by shindig is similar, if not
> > > > > > identical, to that
> > > > > > > used by
> > > > > > > > > other implementations, but it still remains just an
> > > > > > implementation
> > > > > > > detail.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Something else: Can we assume that all preloaded
> > > > > > content at least
> > > > > > > allow
> > > > > > > > > caching during the lifetime of that single gadget
> > > > > > instance? It wouldn't
> > > > > > > make
> > > > > > > > > much sense to preload something that has a no-cache
> > > > > > directive...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I don't see that as being incompatible. Preloading
> > > > > > something that
> > > > > > > isn't
> > > > > > > > > cacheable just means that I have to take care to refetch
> > > > > > it every gadget
> > > > > > > > > render. Not ideal, certainly, but if the gadget author
> > > > > > would be doing a
> > > > > > > > > makeRequest anyway, it's a lot better to incur that
> > > > > > latency during the
> > > > > > > > > preload in most cases than it is to incur it after the
> > > > > > gadget has been
> > > > > > > > > rendered.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 15, 2008 at 2:38 AM, Kevin Brown <
> > > > > > etnu@google.com>
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden <
> > > > > > bruno@google.com>
> > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > There's some redundancy here because both the
> > > > > > Preload and the
> > > > > > > > > io.makeRequest have to specify a signed fetch. Is there
> > > > > > any way to avoid
> > > > > > > > > this redundancy? Along those lines, what happens if the
> > > > > > Preload is
> > > > > > > signed
> > > > > > > > > but not the makeRequest? An author could easily try to do
> > > > > > a preload and
> > > > > > > yet
> > > > > > > > > have it fail for simple reasons.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > <Preload href="http://www.myhost.com/getdata"
> > > > > > authz="signed" />
> > > > > > > > > > > > >
> > > > > > > > > > > > > The content of a Preload request is made available
> > > > > > to the gadget
> > > > > > > > > developer by making the equivalent gadgets.io.makeRequest
> > > > > > call on the
> > > > > > > > > browser without making a remote call. E.g.
> > > > > > > > > > > > >
> > > > > > > > > > > > > var params = {}; // forgot "SIGNED" param
> > > > > > > > > > > > >
> > > > > > > > > > > > > gadgets.io.makeRequest("
> > > > > > http://www.myhost.com/getdata",
> > > > > > > callback,
> > > > > > > > > params);
> > > > > > > > > > > > >
> > > > > > > > > > > > > Is this makeRequest preloaded or not?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > <Preload> is already in the spec (and tied to
> > > > > > makeRequest) -- the
> > > > > > > only
> > > > > > > > > change Louis is proposing is allowing authentication
> > > > > > (something which
> > > > > > > has
> > > > > > > > > been shown to be necessary by most containers). This
> > > > > > functionality is
> > > > > > > purely
> > > > > > > > > an optimization.
> > > > > > > > > > > >
> > > > > > > > > > > > The need for redundancy is ugly, but I don't see any
> > > > > > other way to
> > > > > > > do
> > > > > > > > > it without making backwards compatibility very difficult.
> > > > > > Under Louis
> > > > > > > > > proposed model, a gadget server that didn't support
> > > > > > <Preload> would
> > > > > > > still
> > > > > > > > > work with the gadget, which seems like a pretty big
> > > > > > advantage to me,
> > > > > > > though
> > > > > > > > > we would probably want to be explicit and require that the
> > > > > > authz used
> > > > > > > > > between <Preload> and makeRequest be identical.
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > ~Kevin
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > ~Kevin
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ~Kevin
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: Proposal : Modify gadget spec to allow for authenticated/signed
preloads & allow preloads to be defined per Content section.
Posted by Cassie <do...@google.com>.
btw - this will go on record for 0.9 stuff.
for 0.8 we will add the simple thing described above and Shindig (or other
containers) can of course add extensions.
sorry to interrupt, discuss away!
- cassie
On Fri, May 2, 2008 at 11:25 PM, Brian Eaton <be...@google.com> wrote:
>
> For the record, I'd rather see additional parameters to SIGNED
> requests rather than new signing methods like SIGNED_FOO. I suspect
> SIGNED_FOO will be shortly followed by SIGNED_FOO_BAR5_NOTQUUX, etc...
> For this specific case, how about
>
> authz=signed&viewer=false
>
> The signed friends use case would later be handled with
>
> authz=signed&owner-friends=alice,bob,claire
>
> etc...
>
> Cheers,
> Brian
>
>
> On Fri, May 2, 2008 at 12:18 AM, Louis Ryan <lr...@google.com> wrote:
> > Perhaps not.
> >
> > If the container is not exposing viewer information to the gadget under
> its
> > ACLing rules SIGNED may already not include viewer. It seems SIGNED_OWNER
> > just makes this explicit. Not sure how to interpret SIGNED &user=viewer
> when
> > viewer isnt accessible?
> >
> >
> >
> >
> >
> > On Thu, May 1, 2008 at 7:56 PM, Kevin Brown <et...@google.com> wrote:
> > >
> > > On Thu, May 1, 2008 at 7:15 PM, Louis Ryan <lr...@google.com> wrote:
> > >
> > >
> > >
> > > > I'd like to propose some amendments to this spec, possibly for 0.8 if
> > people are willing but if not at least for experimental inclusion in
> Shindig
> > in short-order.
> > > >
> > > > 1. Add support for a 'view' attribute which identifies when a Preload
> > should be executed based on which content sections are rendered. This is
> to
> > allow for different preloads on different views. The value of the
> attribute
> > is a comma-separated list of views. If the attributes is omitted the
> preload
> > is always executed
> > > >
> > > > 2. Add support for a new authentication mode. SIGNED_OWNER_ONLY. In
> this
> > situation the viewer information is omitted from the signed request. This
> is
> > useful when the information returned by the backend does not care about
> the
> > viewer. A concrete example is a profile view which is non-interactive but
> > shows content that is entirely contextual to the owner. Omitting the
> viewer
> > from requests for this kind of information allows for significantly
> better
> > caching throughout the stack Containers which do not implement this mode
> can
> > fallback to SIGNED.
> > >
> > >
> > > Is a new auth mode really the right thing here? Why not authz="signed"
> > user="(owner | viewer | both)".
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > > Thoughts?
> > > >
> > > > -Louis
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Apr 24, 2008 at 8:44 AM, Cassie <do...@google.com> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Okay, so Louis, Brian Eaton, Reinoudm and I are +1s and I think
> Kevin
> > is a +1.
> > > > > As long as there aren't any objections this will go into 0.8
> > > > >
> > > > > - Cassie
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 21, 2008 at 11:46 PM, Kevin Brown <et...@google.com>
> wrote:
> > > > >
> > > > > >
> > > > > > On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <beaton@google.com
> >
> > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > So long as we're clear in the spec about what is supposed to
> > happen if
> > > > > > > a preload is done for GET http://something, and then the
> gadget
> > does
> > > > > > > POST http://something instead. Those are different requests,
> a
> > > > > > > preload for one should not impact the other.
> > > > > >
> > > > > >
> > > > > > Just changing the verb is one thing, but actually attaching a
> post
> > body here seems really bizarre.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Doing preloads only for GET requests sounds reasonable.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Apr 21, 2008 at 9:58 AM, Louis Ryan <lr...@google.com>
> > wrote:
> > > > > > > > For the moment just authz, if people have strong feelings
> about
> > method,
> > > > > > > > post-body etc Im fine to adjust.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Apr 21, 2008 at 7:41 AM, Brian Eaton <
> beaton@google.com>
> > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > I read the proposal differently. Any parameter that can be
> > passed to
> > > > > > > > > makeRequest (HTTP, method, post body, etc...) should be an
> > optional
> > > > > > > > > attribute for Preload as well. Or is that not what Louis
> was
> > trying
> > > > > > > > > to say?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Apr 21, 2008 at 4:33 AM, Cassie <do...@google.com>
> > wrote:
> > > > > > > > > > So, to be clear, the only spec change here is to add the
> > "authz"
> > > > > > > > attribute
> > > > > > > > > > to the "Preload" element, which would be interpreted as
> > Louis described
> > > > > > > > > > above.
> > > > > > > > > >
> > > > > > > > > > Thanks.
> > > > > > > > > > - Cassie
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Apr 15, 2008 at 12:56 PM, Kevin Brown
> > <et...@google.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst
> > <re...@hyves.nl>
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > + 1 on the theoretical side, especially since
> containers
> > don't have
> > > > > > > > to
> > > > > > > > > > support the preload (and everything will still work,
> > although with some
> > > > > > > > more
> > > > > > > > > > latency)
> > > > > > > > > > > >
> > > > > > > > > > > > On the practical side: I don't think that the st is
> sent
> > to shindig
> > > > > > > > at
> > > > > > > > > > the moment, so preloading a signed request may be
> difficult.
> > We
> > > > > > > > shouldn't
> > > > > > > > > > confuse spec with practical implementation though.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > This is an implementation detail that is easily
> remedied.
> > The security
> > > > > > > > > > token solution used by shindig is similar, if not
> identical,
> > to that
> > > > > > > > used by
> > > > > > > > > > other implementations, but it still remains just an
> > implementation
> > > > > > > > detail.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Something else: Can we assume that all preloaded
> content
> > at least
> > > > > > > > allow
> > > > > > > > > > caching during the lifetime of that single gadget
> instance?
> > It wouldn't
> > > > > > > > make
> > > > > > > > > > much sense to preload something that has a no-cache
> > directive...
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I don't see that as being incompatible. Preloading
> > something that
> > > > > > > > isn't
> > > > > > > > > > cacheable just means that I have to take care to refetch
> it
> > every gadget
> > > > > > > > > > render. Not ideal, certainly, but if the gadget author
> would
> > be doing a
> > > > > > > > > > makeRequest anyway, it's a lot better to incur that
> latency
> > during the
> > > > > > > > > > preload in most cases than it is to incur it after the
> > gadget has been
> > > > > > > > > > rendered.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Apr 15, 2008 at 2:38 AM, Kevin Brown
> > <et...@google.com>
> > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden
> > <br...@google.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > There's some redundancy here because both the
> > Preload and the
> > > > > > > > > > io.makeRequest have to specify a signed fetch. Is there
> any
> > way to avoid
> > > > > > > > > > this redundancy? Along those lines, what happens if the
> > Preload is
> > > > > > > > signed
> > > > > > > > > > but not the makeRequest? An author could easily try to do
> a
> > preload and
> > > > > > > > yet
> > > > > > > > > > have it fail for simple reasons.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > <Preload href="http://www.myhost.com/getdata"
> > authz="signed" />
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The content of a Preload request is made
> available
> > to the gadget
> > > > > > > > > > developer by making the equivalent gadgets.io.makeRequest
> > call on the
> > > > > > > > > > browser without making a remote call. E.g.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > var params = {}; // forgot "SIGNED" param
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > gadgets.io.makeRequest("http://www.myhost.com/getdata",
> > > > > > > > callback,
> > > > > > > > > > params);
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Is this makeRequest preloaded or not?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > <Preload> is already in the spec (and tied to
> > makeRequest) -- the
> > > > > > > > only
> > > > > > > > > > change Louis is proposing is allowing authentication
> > (something which
> > > > > > > > has
> > > > > > > > > > been shown to be necessary by most containers). This
> > functionality is
> > > > > > > > purely
> > > > > > > > > > an optimization.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The need for redundancy is ugly, but I don't see
> any
> > other way to
> > > > > > > > do
> > > > > > > > > > it without making backwards compatibility very difficult.
> > Under Louis
> > > > > > > > > > proposed model, a gadget server that didn't support
> > <Preload> would
> > > > > > > > still
> > > > > > > > > > work with the gadget, which seems like a pretty big
> > advantage to me,
> > > > > > > > though
> > > > > > > > > > we would probably want to be explicit and require that
> the
> > authz used
> > > > > > > > > > between <Preload> and makeRequest be identical.
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > ~Kevin
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > ~Kevin
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ~Kevin
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > >
> >
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: Proposal : Modify gadget spec to allow for authenticated/signed preloads & allow preloads to be defined per Content section.
Posted by Kevin Brown <et...@google.com>.
On Mon, May 5, 2008 at 1:52 PM, Louis Ryan <lr...@google.com> wrote:
> I think we need something that is reasonably concise to use in the Preload
> XML element and in the JSON bundle for makeRequest
>
> Adding an attribute for possible variant seems verbose but Im willing to
> go
> with it experimentally.
>
> <Preload .... viewer="[true|false]" owner="[true|false]" ..
>
> it is.
>
> I don't think this is the appropriate vehicle to solve the owner-friends
> signing problem and folks will just have to wait for the RESTful API for
> that.
That makes sense to me as well. Trying to pass friends in makeRequest calls
is painful.
>
> -Louis
>
>
> On Fri, May 2, 2008 at 2:25 PM, Brian Eaton <be...@google.com> wrote:
>
> >
> > For the record, I'd rather see additional parameters to SIGNED
> > requests rather than new signing methods like SIGNED_FOO. I suspect
> > SIGNED_FOO will be shortly followed by SIGNED_FOO_BAR5_NOTQUUX, etc...
> > For this specific case, how about
> >
> > authz=signed&viewer=false
> >
> > The signed friends use case would later be handled with
> >
> > authz=signed&owner-friends=alice,bob,claire
> >
> > etc...
> >
> > Cheers,
> > Brian
> >
> >
> > On Fri, May 2, 2008 at 12:18 AM, Louis Ryan <lr...@google.com> wrote:
> > > Perhaps not.
> > >
> > > If the container is not exposing viewer information to the gadget
> under
> > its
> > > ACLing rules SIGNED may already not include viewer. It seems
> > SIGNED_OWNER
> > > just makes this explicit. Not sure how to interpret SIGNED
> &user=viewer
> > when
> > > viewer isnt accessible?
> > >
> > >
> > >
> > >
> > >
> > > On Thu, May 1, 2008 at 7:56 PM, Kevin Brown <et...@google.com> wrote:
> > > >
> > > > On Thu, May 1, 2008 at 7:15 PM, Louis Ryan <lr...@google.com> wrote:
> > > >
> > > >
> > > >
> > > > > I'd like to propose some amendments to this spec, possibly for 0.8
> > if
> > > people are willing but if not at least for experimental inclusion in
> > Shindig
> > > in short-order.
> > > > >
> > > > > 1. Add support for a 'view' attribute which identifies when a
> > Preload
> > > should be executed based on which content sections are rendered. This
> is
> > to
> > > allow for different preloads on different views. The value of the
> > attribute
> > > is a comma-separated list of views. If the attributes is omitted the
> > preload
> > > is always executed
> > > > >
> > > > > 2. Add support for a new authentication mode. SIGNED_OWNER_ONLY.
> In
> > this
> > > situation the viewer information is omitted from the signed request.
> > This is
> > > useful when the information returned by the backend does not care
> about
> > the
> > > viewer. A concrete example is a profile view which is non-interactive
> > but
> > > shows content that is entirely contextual to the owner. Omitting the
> > viewer
> > > from requests for this kind of information allows for significantly
> > better
> > > caching throughout the stack Containers which do not implement this
> mode
> > can
> > > fallback to SIGNED.
> > > >
> > > >
> > > > Is a new auth mode really the right thing here? Why not
> > authz="signed"
> > > user="(owner | viewer | both)".
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > -Louis
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Apr 24, 2008 at 8:44 AM, Cassie <do...@google.com> wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Okay, so Louis, Brian Eaton, Reinoudm and I are +1s and I think
> > Kevin
> > > is a +1.
> > > > > > As long as there aren't any objections this will go into 0.8
> > > > > >
> > > > > > - Cassie
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 21, 2008 at 11:46 PM, Kevin Brown <et...@google.com>
> > wrote:
> > > > > >
> > > > > > >
> > > > > > > On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <
> beaton@google.com
> > >
> > > wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > So long as we're clear in the spec about what is supposed to
> > > happen if
> > > > > > > > a preload is done for GET http://something, and then the
> > gadget
> > > does
> > > > > > > > POST http://something instead. Those are different
> requests,
> > a
> > > > > > > > preload for one should not impact the other.
> > > > > > >
> > > > > > >
> > > > > > > Just changing the verb is one thing, but actually attaching a
> > post
> > > body here seems really bizarre.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Doing preloads only for GET requests sounds reasonable.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Apr 21, 2008 at 9:58 AM, Louis Ryan <
> lryan@google.com>
> > > wrote:
> > > > > > > > > For the moment just authz, if people have strong feelings
> > about
> > > method,
> > > > > > > > > post-body etc Im fine to adjust.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Apr 21, 2008 at 7:41 AM, Brian Eaton <
> > beaton@google.com>
> > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I read the proposal differently. Any parameter that can
> > be
> > > passed to
> > > > > > > > > > makeRequest (HTTP, method, post body, etc...) should be
> an
> > > optional
> > > > > > > > > > attribute for Preload as well. Or is that not what
> Louis
> > was
> > > trying
> > > > > > > > > > to say?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Mon, Apr 21, 2008 at 4:33 AM, Cassie <doll@google.com
> >
> > > wrote:
> > > > > > > > > > > So, to be clear, the only spec change here is to add
> the
> > > "authz"
> > > > > > > > > attribute
> > > > > > > > > > > to the "Preload" element, which would be interpreted
> as
> > > Louis described
> > > > > > > > > > > above.
> > > > > > > > > > >
> > > > > > > > > > > Thanks.
> > > > > > > > > > > - Cassie
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 15, 2008 at 12:56 PM, Kevin Brown
> > > <et...@google.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst
> > > <re...@hyves.nl>
> > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > + 1 on the theoretical side, especially since
> > containers
> > > don't have
> > > > > > > > > to
> > > > > > > > > > > support the preload (and everything will still work,
> > > although with some
> > > > > > > > > more
> > > > > > > > > > > latency)
> > > > > > > > > > > > >
> > > > > > > > > > > > > On the practical side: I don't think that the st
> is
> > sent
> > > to shindig
> > > > > > > > > at
> > > > > > > > > > > the moment, so preloading a signed request may be
> > difficult.
> > > We
> > > > > > > > > shouldn't
> > > > > > > > > > > confuse spec with practical implementation though.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > This is an implementation detail that is easily
> > remedied.
> > > The security
> > > > > > > > > > > token solution used by shindig is similar, if not
> > identical,
> > > to that
> > > > > > > > > used by
> > > > > > > > > > > other implementations, but it still remains just an
> > > implementation
> > > > > > > > > detail.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > Something else: Can we assume that all preloaded
> > content
> > > at least
> > > > > > > > > allow
> > > > > > > > > > > caching during the lifetime of that single gadget
> > instance?
> > > It wouldn't
> > > > > > > > > make
> > > > > > > > > > > much sense to preload something that has a no-cache
> > > directive...
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I don't see that as being incompatible. Preloading
> > > something that
> > > > > > > > > isn't
> > > > > > > > > > > cacheable just means that I have to take care to
> refetch
> > it
> > > every gadget
> > > > > > > > > > > render. Not ideal, certainly, but if the gadget author
> > would
> > > be doing a
> > > > > > > > > > > makeRequest anyway, it's a lot better to incur that
> > latency
> > > during the
> > > > > > > > > > > preload in most cases than it is to incur it after the
> > > gadget has been
> > > > > > > > > > > rendered.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Apr 15, 2008 at 2:38 AM, Kevin Brown
> > > <et...@google.com>
> > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden
> > > <br...@google.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > There's some redundancy here because both the
> > > Preload and the
> > > > > > > > > > > io.makeRequest have to specify a signed fetch. Is
> there
> > any
> > > way to avoid
> > > > > > > > > > > this redundancy? Along those lines, what happens if
> the
> > > Preload is
> > > > > > > > > signed
> > > > > > > > > > > but not the makeRequest? An author could easily try to
> > do a
> > > preload and
> > > > > > > > > yet
> > > > > > > > > > > have it fail for simple reasons.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > <Preload href="http://www.myhost.com/getdata"
> > > authz="signed" />
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The content of a Preload request is made
> > available
> > > to the gadget
> > > > > > > > > > > developer by making the equivalent
> > gadgets.io.makeRequest
> > > call on the
> > > > > > > > > > > browser without making a remote call. E.g.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > var params = {}; // forgot "SIGNED" param
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > gadgets.io.makeRequest("http://www.myhost.com/getdata",
> > > > > > > > > callback,
> > > > > > > > > > > params);
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Is this makeRequest preloaded or not?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > <Preload> is already in the spec (and tied to
> > > makeRequest) -- the
> > > > > > > > > only
> > > > > > > > > > > change Louis is proposing is allowing authentication
> > > (something which
> > > > > > > > > has
> > > > > > > > > > > been shown to be necessary by most containers). This
> > > functionality is
> > > > > > > > > purely
> > > > > > > > > > > an optimization.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The need for redundancy is ugly, but I don't see
> > any
> > > other way to
> > > > > > > > > do
> > > > > > > > > > > it without making backwards compatibility very
> > difficult.
> > > Under Louis
> > > > > > > > > > > proposed model, a gadget server that didn't support
> > > <Preload> would
> > > > > > > > > still
> > > > > > > > > > > work with the gadget, which seems like a pretty big
> > > advantage to me,
> > > > > > > > > though
> > > > > > > > > > > we would probably want to be explicit and require that
> > the
> > > authz used
> > > > > > > > > > > between <Preload> and makeRequest be identical.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > ~Kevin
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > ~Kevin
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > ~Kevin
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > >
> > >
> >
> > --~--~---------~--~----~------------~-------~--~----~
> > You received this message because you are subscribed to the Google
> Groups
> > "OpenSocial and Gadgets Specification Discussion" group.
> > To post to this group, send email to
> > opensocial-and-gadgets-spec@googlegroups.com
> > To unsubscribe from this group, send email to
> > opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> > -~----------~----~----~----~------~----~------~--~---
> >
> >
>
Re: Proposal : Modify gadget spec to allow for authenticated/signed preloads & allow preloads to be defined per Content section.
Posted by Louis Ryan <lr...@google.com>.
I think we need something that is reasonably concise to use in the Preload
XML element and in the JSON bundle for makeRequest
Adding an attribute for possible variant seems verbose but Im willing to go
with it experimentally.
<Preload .... viewer="[true|false]" owner="[true|false]" ..
it is.
I don't think this is the appropriate vehicle to solve the owner-friends
signing problem and folks will just have to wait for the RESTful API for
that.
-Louis
On Fri, May 2, 2008 at 2:25 PM, Brian Eaton <be...@google.com> wrote:
>
> For the record, I'd rather see additional parameters to SIGNED
> requests rather than new signing methods like SIGNED_FOO. I suspect
> SIGNED_FOO will be shortly followed by SIGNED_FOO_BAR5_NOTQUUX, etc...
> For this specific case, how about
>
> authz=signed&viewer=false
>
> The signed friends use case would later be handled with
>
> authz=signed&owner-friends=alice,bob,claire
>
> etc...
>
> Cheers,
> Brian
>
>
> On Fri, May 2, 2008 at 12:18 AM, Louis Ryan <lr...@google.com> wrote:
> > Perhaps not.
> >
> > If the container is not exposing viewer information to the gadget under
> its
> > ACLing rules SIGNED may already not include viewer. It seems
> SIGNED_OWNER
> > just makes this explicit. Not sure how to interpret SIGNED &user=viewer
> when
> > viewer isnt accessible?
> >
> >
> >
> >
> >
> > On Thu, May 1, 2008 at 7:56 PM, Kevin Brown <et...@google.com> wrote:
> > >
> > > On Thu, May 1, 2008 at 7:15 PM, Louis Ryan <lr...@google.com> wrote:
> > >
> > >
> > >
> > > > I'd like to propose some amendments to this spec, possibly for 0.8
> if
> > people are willing but if not at least for experimental inclusion in
> Shindig
> > in short-order.
> > > >
> > > > 1. Add support for a 'view' attribute which identifies when a
> Preload
> > should be executed based on which content sections are rendered. This is
> to
> > allow for different preloads on different views. The value of the
> attribute
> > is a comma-separated list of views. If the attributes is omitted the
> preload
> > is always executed
> > > >
> > > > 2. Add support for a new authentication mode. SIGNED_OWNER_ONLY. In
> this
> > situation the viewer information is omitted from the signed request.
> This is
> > useful when the information returned by the backend does not care about
> the
> > viewer. A concrete example is a profile view which is non-interactive
> but
> > shows content that is entirely contextual to the owner. Omitting the
> viewer
> > from requests for this kind of information allows for significantly
> better
> > caching throughout the stack Containers which do not implement this mode
> can
> > fallback to SIGNED.
> > >
> > >
> > > Is a new auth mode really the right thing here? Why not
> authz="signed"
> > user="(owner | viewer | both)".
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > > Thoughts?
> > > >
> > > > -Louis
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Apr 24, 2008 at 8:44 AM, Cassie <do...@google.com> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Okay, so Louis, Brian Eaton, Reinoudm and I are +1s and I think
> Kevin
> > is a +1.
> > > > > As long as there aren't any objections this will go into 0.8
> > > > >
> > > > > - Cassie
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 21, 2008 at 11:46 PM, Kevin Brown <et...@google.com>
> wrote:
> > > > >
> > > > > >
> > > > > > On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <beaton@google.com
> >
> > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > So long as we're clear in the spec about what is supposed to
> > happen if
> > > > > > > a preload is done for GET http://something, and then the
> gadget
> > does
> > > > > > > POST http://something instead. Those are different requests,
> a
> > > > > > > preload for one should not impact the other.
> > > > > >
> > > > > >
> > > > > > Just changing the verb is one thing, but actually attaching a
> post
> > body here seems really bizarre.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Doing preloads only for GET requests sounds reasonable.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Apr 21, 2008 at 9:58 AM, Louis Ryan <lr...@google.com>
> > wrote:
> > > > > > > > For the moment just authz, if people have strong feelings
> about
> > method,
> > > > > > > > post-body etc Im fine to adjust.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Apr 21, 2008 at 7:41 AM, Brian Eaton <
> beaton@google.com>
> > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > I read the proposal differently. Any parameter that can
> be
> > passed to
> > > > > > > > > makeRequest (HTTP, method, post body, etc...) should be an
> > optional
> > > > > > > > > attribute for Preload as well. Or is that not what Louis
> was
> > trying
> > > > > > > > > to say?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Apr 21, 2008 at 4:33 AM, Cassie <do...@google.com>
> > wrote:
> > > > > > > > > > So, to be clear, the only spec change here is to add the
> > "authz"
> > > > > > > > attribute
> > > > > > > > > > to the "Preload" element, which would be interpreted as
> > Louis described
> > > > > > > > > > above.
> > > > > > > > > >
> > > > > > > > > > Thanks.
> > > > > > > > > > - Cassie
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Apr 15, 2008 at 12:56 PM, Kevin Brown
> > <et...@google.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst
> > <re...@hyves.nl>
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > + 1 on the theoretical side, especially since
> containers
> > don't have
> > > > > > > > to
> > > > > > > > > > support the preload (and everything will still work,
> > although with some
> > > > > > > > more
> > > > > > > > > > latency)
> > > > > > > > > > > >
> > > > > > > > > > > > On the practical side: I don't think that the st is
> sent
> > to shindig
> > > > > > > > at
> > > > > > > > > > the moment, so preloading a signed request may be
> difficult.
> > We
> > > > > > > > shouldn't
> > > > > > > > > > confuse spec with practical implementation though.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > This is an implementation detail that is easily
> remedied.
> > The security
> > > > > > > > > > token solution used by shindig is similar, if not
> identical,
> > to that
> > > > > > > > used by
> > > > > > > > > > other implementations, but it still remains just an
> > implementation
> > > > > > > > detail.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Something else: Can we assume that all preloaded
> content
> > at least
> > > > > > > > allow
> > > > > > > > > > caching during the lifetime of that single gadget
> instance?
> > It wouldn't
> > > > > > > > make
> > > > > > > > > > much sense to preload something that has a no-cache
> > directive...
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I don't see that as being incompatible. Preloading
> > something that
> > > > > > > > isn't
> > > > > > > > > > cacheable just means that I have to take care to refetch
> it
> > every gadget
> > > > > > > > > > render. Not ideal, certainly, but if the gadget author
> would
> > be doing a
> > > > > > > > > > makeRequest anyway, it's a lot better to incur that
> latency
> > during the
> > > > > > > > > > preload in most cases than it is to incur it after the
> > gadget has been
> > > > > > > > > > rendered.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Apr 15, 2008 at 2:38 AM, Kevin Brown
> > <et...@google.com>
> > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden
> > <br...@google.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > There's some redundancy here because both the
> > Preload and the
> > > > > > > > > > io.makeRequest have to specify a signed fetch. Is there
> any
> > way to avoid
> > > > > > > > > > this redundancy? Along those lines, what happens if the
> > Preload is
> > > > > > > > signed
> > > > > > > > > > but not the makeRequest? An author could easily try to
> do a
> > preload and
> > > > > > > > yet
> > > > > > > > > > have it fail for simple reasons.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > <Preload href="http://www.myhost.com/getdata"
> > authz="signed" />
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The content of a Preload request is made
> available
> > to the gadget
> > > > > > > > > > developer by making the equivalent
> gadgets.io.makeRequest
> > call on the
> > > > > > > > > > browser without making a remote call. E.g.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > var params = {}; // forgot "SIGNED" param
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > gadgets.io.makeRequest("http://www.myhost.com/getdata",
> > > > > > > > callback,
> > > > > > > > > > params);
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Is this makeRequest preloaded or not?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > <Preload> is already in the spec (and tied to
> > makeRequest) -- the
> > > > > > > > only
> > > > > > > > > > change Louis is proposing is allowing authentication
> > (something which
> > > > > > > > has
> > > > > > > > > > been shown to be necessary by most containers). This
> > functionality is
> > > > > > > > purely
> > > > > > > > > > an optimization.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The need for redundancy is ugly, but I don't see
> any
> > other way to
> > > > > > > > do
> > > > > > > > > > it without making backwards compatibility very
> difficult.
> > Under Louis
> > > > > > > > > > proposed model, a gadget server that didn't support
> > <Preload> would
> > > > > > > > still
> > > > > > > > > > work with the gadget, which seems like a pretty big
> > advantage to me,
> > > > > > > > though
> > > > > > > > > > we would probably want to be explicit and require that
> the
> > authz used
> > > > > > > > > > between <Preload> and makeRequest be identical.
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > ~Kevin
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > ~Kevin
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ~Kevin
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > >
> >
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: Proposal : Modify gadget spec to allow for authenticated/signed preloads & allow preloads to be defined per Content section.
Posted by Brian Eaton <be...@google.com>.
For the record, I'd rather see additional parameters to SIGNED
requests rather than new signing methods like SIGNED_FOO. I suspect
SIGNED_FOO will be shortly followed by SIGNED_FOO_BAR5_NOTQUUX, etc...
For this specific case, how about
authz=signed&viewer=false
The signed friends use case would later be handled with
authz=signed&owner-friends=alice,bob,claire
etc...
Cheers,
Brian
On Fri, May 2, 2008 at 12:18 AM, Louis Ryan <lr...@google.com> wrote:
> Perhaps not.
>
> If the container is not exposing viewer information to the gadget under its
> ACLing rules SIGNED may already not include viewer. It seems SIGNED_OWNER
> just makes this explicit. Not sure how to interpret SIGNED &user=viewer when
> viewer isnt accessible?
>
>
>
>
>
> On Thu, May 1, 2008 at 7:56 PM, Kevin Brown <et...@google.com> wrote:
> >
> > On Thu, May 1, 2008 at 7:15 PM, Louis Ryan <lr...@google.com> wrote:
> >
> >
> >
> > > I'd like to propose some amendments to this spec, possibly for 0.8 if
> people are willing but if not at least for experimental inclusion in Shindig
> in short-order.
> > >
> > > 1. Add support for a 'view' attribute which identifies when a Preload
> should be executed based on which content sections are rendered. This is to
> allow for different preloads on different views. The value of the attribute
> is a comma-separated list of views. If the attributes is omitted the preload
> is always executed
> > >
> > > 2. Add support for a new authentication mode. SIGNED_OWNER_ONLY. In this
> situation the viewer information is omitted from the signed request. This is
> useful when the information returned by the backend does not care about the
> viewer. A concrete example is a profile view which is non-interactive but
> shows content that is entirely contextual to the owner. Omitting the viewer
> from requests for this kind of information allows for significantly better
> caching throughout the stack Containers which do not implement this mode can
> fallback to SIGNED.
> >
> >
> > Is a new auth mode really the right thing here? Why not authz="signed"
> user="(owner | viewer | both)".
> >
> >
> >
> >
> > >
> > >
> > > Thoughts?
> > >
> > > -Louis
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Apr 24, 2008 at 8:44 AM, Cassie <do...@google.com> wrote:
> > >
> > > > +1
> > > >
> > > > Okay, so Louis, Brian Eaton, Reinoudm and I are +1s and I think Kevin
> is a +1.
> > > > As long as there aren't any objections this will go into 0.8
> > > >
> > > > - Cassie
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Apr 21, 2008 at 11:46 PM, Kevin Brown <et...@google.com> wrote:
> > > >
> > > > >
> > > > > On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <be...@google.com>
> wrote:
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > So long as we're clear in the spec about what is supposed to
> happen if
> > > > > > a preload is done for GET http://something, and then the gadget
> does
> > > > > > POST http://something instead. Those are different requests, a
> > > > > > preload for one should not impact the other.
> > > > >
> > > > >
> > > > > Just changing the verb is one thing, but actually attaching a post
> body here seems really bizarre.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > Doing preloads only for GET requests sounds reasonable.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 21, 2008 at 9:58 AM, Louis Ryan <lr...@google.com>
> wrote:
> > > > > > > For the moment just authz, if people have strong feelings about
> method,
> > > > > > > post-body etc Im fine to adjust.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Apr 21, 2008 at 7:41 AM, Brian Eaton <be...@google.com>
> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > I read the proposal differently. Any parameter that can be
> passed to
> > > > > > > > makeRequest (HTTP, method, post body, etc...) should be an
> optional
> > > > > > > > attribute for Preload as well. Or is that not what Louis was
> trying
> > > > > > > > to say?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Apr 21, 2008 at 4:33 AM, Cassie <do...@google.com>
> wrote:
> > > > > > > > > So, to be clear, the only spec change here is to add the
> "authz"
> > > > > > > attribute
> > > > > > > > > to the "Preload" element, which would be interpreted as
> Louis described
> > > > > > > > > above.
> > > > > > > > >
> > > > > > > > > Thanks.
> > > > > > > > > - Cassie
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Apr 15, 2008 at 12:56 PM, Kevin Brown
> <et...@google.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst
> <re...@hyves.nl>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > + 1 on the theoretical side, especially since containers
> don't have
> > > > > > > to
> > > > > > > > > support the preload (and everything will still work,
> although with some
> > > > > > > more
> > > > > > > > > latency)
> > > > > > > > > > >
> > > > > > > > > > > On the practical side: I don't think that the st is sent
> to shindig
> > > > > > > at
> > > > > > > > > the moment, so preloading a signed request may be difficult.
> We
> > > > > > > shouldn't
> > > > > > > > > confuse spec with practical implementation though.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > This is an implementation detail that is easily remedied.
> The security
> > > > > > > > > token solution used by shindig is similar, if not identical,
> to that
> > > > > > > used by
> > > > > > > > > other implementations, but it still remains just an
> implementation
> > > > > > > detail.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Something else: Can we assume that all preloaded content
> at least
> > > > > > > allow
> > > > > > > > > caching during the lifetime of that single gadget instance?
> It wouldn't
> > > > > > > make
> > > > > > > > > much sense to preload something that has a no-cache
> directive...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I don't see that as being incompatible. Preloading
> something that
> > > > > > > isn't
> > > > > > > > > cacheable just means that I have to take care to refetch it
> every gadget
> > > > > > > > > render. Not ideal, certainly, but if the gadget author would
> be doing a
> > > > > > > > > makeRequest anyway, it's a lot better to incur that latency
> during the
> > > > > > > > > preload in most cases than it is to incur it after the
> gadget has been
> > > > > > > > > rendered.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 15, 2008 at 2:38 AM, Kevin Brown
> <et...@google.com>
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden
> <br...@google.com>
> > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > There's some redundancy here because both the
> Preload and the
> > > > > > > > > io.makeRequest have to specify a signed fetch. Is there any
> way to avoid
> > > > > > > > > this redundancy? Along those lines, what happens if the
> Preload is
> > > > > > > signed
> > > > > > > > > but not the makeRequest? An author could easily try to do a
> preload and
> > > > > > > yet
> > > > > > > > > have it fail for simple reasons.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > <Preload href="http://www.myhost.com/getdata"
> authz="signed" />
> > > > > > > > > > > > >
> > > > > > > > > > > > > The content of a Preload request is made available
> to the gadget
> > > > > > > > > developer by making the equivalent gadgets.io.makeRequest
> call on the
> > > > > > > > > browser without making a remote call. E.g.
> > > > > > > > > > > > >
> > > > > > > > > > > > > var params = {}; // forgot "SIGNED" param
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> gadgets.io.makeRequest("http://www.myhost.com/getdata",
> > > > > > > callback,
> > > > > > > > > params);
> > > > > > > > > > > > >
> > > > > > > > > > > > > Is this makeRequest preloaded or not?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > <Preload> is already in the spec (and tied to
> makeRequest) -- the
> > > > > > > only
> > > > > > > > > change Louis is proposing is allowing authentication
> (something which
> > > > > > > has
> > > > > > > > > been shown to be necessary by most containers). This
> functionality is
> > > > > > > purely
> > > > > > > > > an optimization.
> > > > > > > > > > > >
> > > > > > > > > > > > The need for redundancy is ugly, but I don't see any
> other way to
> > > > > > > do
> > > > > > > > > it without making backwards compatibility very difficult.
> Under Louis
> > > > > > > > > proposed model, a gadget server that didn't support
> <Preload> would
> > > > > > > still
> > > > > > > > > work with the gadget, which seems like a pretty big
> advantage to me,
> > > > > > > though
> > > > > > > > > we would probably want to be explicit and require that the
> authz used
> > > > > > > > > between <Preload> and makeRequest be identical.
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > ~Kevin
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > ~Kevin
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ~Kevin
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
>
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: Proposal : Modify gadget spec to allow for authenticated/signed preloads & allow preloads to be defined per Content section.
Posted by Louis Ryan <lr...@google.com>.
Perhaps not.
If the container is not exposing viewer information to the gadget under its
ACLing rules SIGNED may already not include viewer. It seems SIGNED_OWNER
just makes this explicit. Not sure how to interpret SIGNED &user=viewer when
viewer isnt accessible?
On Thu, May 1, 2008 at 7:56 PM, Kevin Brown <et...@google.com> wrote:
> On Thu, May 1, 2008 at 7:15 PM, Louis Ryan <lr...@google.com> wrote:
>
> > I'd like to propose some amendments to this spec, possibly for 0.8 if
> > people are willing but if not at least for experimental inclusion in Shindig
> > in short-order.
> >
> > 1. Add support for a 'view' attribute which identifies when a Preload
> > should be executed based on which content sections are rendered. This is to
> > allow for different preloads on different views. The value of the attribute
> > is a comma-separated list of views. If the attributes is omitted the preload
> > is always executed
> >
> > 2. Add support for a new authentication mode. SIGNED_OWNER_ONLY. In this
> > situation the viewer information is omitted from the signed request. This is
> > useful when the information returned by the backend does not care about the
> > viewer. A concrete example is a profile view which is non-interactive but
> > shows content that is entirely contextual to the owner. Omitting the viewer
> > from requests for this kind of information allows for significantly better
> > caching throughout the stack Containers which do not implement this mode can
> > fallback to SIGNED.
>
>
> Is a new auth mode really the right thing here? Why not authz="signed"
> user="(owner | viewer | both)".
>
> >
> >
> > Thoughts?
> >
> > -Louis
> >
> >
> >
> >
> > On Thu, Apr 24, 2008 at 8:44 AM, Cassie <do...@google.com> wrote:
> >
> > > +1
> > >
> > > Okay, so Louis, Brian Eaton, Reinoudm and I are +1s and I think Kevin
> > > is a +1.
> > > As long as there aren't any objections this will go into 0.8
> > >
> > > - Cassie
> > >
> > >
> > >
> > >
> > > On Mon, Apr 21, 2008 at 11:46 PM, Kevin Brown <et...@google.com> wrote:
> > >
> > > > On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <be...@google.com>
> > > > wrote:
> > > >
> > > > >
> > > > > So long as we're clear in the spec about what is supposed to
> > > > > happen if
> > > > > a preload is done for GET http://something, and then the gadget
> > > > > does
> > > > > POST http://something instead. Those are different requests, a
> > > > > preload for one should not impact the other.
> > > >
> > > >
> > > > Just changing the verb is one thing, but actually attaching a post
> > > > body here seems really bizarre.
> > > >
> > > >
> > > > >
> > > > > Doing preloads only for GET requests sounds reasonable.
> > > > >
> > > > > On Mon, Apr 21, 2008 at 9:58 AM, Louis Ryan <lr...@google.com>
> > > > > wrote:
> > > > > > For the moment just authz, if people have strong feelings about
> > > > > method,
> > > > > > post-body etc Im fine to adjust.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 21, 2008 at 7:41 AM, Brian Eaton <be...@google.com>
> > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > I read the proposal differently. Any parameter that can be
> > > > > passed to
> > > > > > > makeRequest (HTTP, method, post body, etc...) should be an
> > > > > optional
> > > > > > > attribute for Preload as well. Or is that not what Louis was
> > > > > trying
> > > > > > > to say?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Apr 21, 2008 at 4:33 AM, Cassie <do...@google.com>
> > > > > wrote:
> > > > > > > > So, to be clear, the only spec change here is to add the
> > > > > "authz"
> > > > > > attribute
> > > > > > > > to the "Preload" element, which would be interpreted as
> > > > > Louis described
> > > > > > > > above.
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > > - Cassie
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Apr 15, 2008 at 12:56 PM, Kevin Brown <
> > > > > etnu@google.com> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst <
> > > > > reinoud@hyves.nl>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > + 1 on the theoretical side, especially since containers
> > > > > don't have
> > > > > > to
> > > > > > > > support the preload (and everything will still work,
> > > > > although with some
> > > > > > more
> > > > > > > > latency)
> > > > > > > > > >
> > > > > > > > > > On the practical side: I don't think that the st is sent
> > > > > to shindig
> > > > > > at
> > > > > > > > the moment, so preloading a signed request may be difficult.
> > > > > We
> > > > > > shouldn't
> > > > > > > > confuse spec with practical implementation though.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > This is an implementation detail that is easily remedied.
> > > > > The security
> > > > > > > > token solution used by shindig is similar, if not identical,
> > > > > to that
> > > > > > used by
> > > > > > > > other implementations, but it still remains just an
> > > > > implementation
> > > > > > detail.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Something else: Can we assume that all preloaded content
> > > > > at least
> > > > > > allow
> > > > > > > > caching during the lifetime of that single gadget instance?
> > > > > It wouldn't
> > > > > > make
> > > > > > > > much sense to preload something that has a no-cache
> > > > > directive...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I don't see that as being incompatible. Preloading
> > > > > something that
> > > > > > isn't
> > > > > > > > cacheable just means that I have to take care to refetch it
> > > > > every gadget
> > > > > > > > render. Not ideal, certainly, but if the gadget author would
> > > > > be doing a
> > > > > > > > makeRequest anyway, it's a lot better to incur that latency
> > > > > during the
> > > > > > > > preload in most cases than it is to incur it after the
> > > > > gadget has been
> > > > > > > > rendered.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Apr 15, 2008 at 2:38 AM, Kevin Brown <
> > > > > etnu@google.com>
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden <
> > > > > bruno@google.com>
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > There's some redundancy here because both the
> > > > > Preload and the
> > > > > > > > io.makeRequest have to specify a signed fetch. Is there any
> > > > > way to avoid
> > > > > > > > this redundancy? Along those lines, what happens if the
> > > > > Preload is
> > > > > > signed
> > > > > > > > but not the makeRequest? An author could easily try to do a
> > > > > preload and
> > > > > > yet
> > > > > > > > have it fail for simple reasons.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > <Preload href="http://www.myhost.com/getdata"
> > > > > authz="signed" />
> > > > > > > > > > > >
> > > > > > > > > > > > The content of a Preload request is made available
> > > > > to the gadget
> > > > > > > > developer by making the equivalent gadgets.io.makeRequest
> > > > > call on the
> > > > > > > > browser without making a remote call. E.g.
> > > > > > > > > > > >
> > > > > > > > > > > > var params = {}; // forgot "SIGNED" param
> > > > > > > > > > > >
> > > > > > > > > > > > gadgets.io.makeRequest("
> > > > > http://www.myhost.com/getdata",
> > > > > > callback,
> > > > > > > > params);
> > > > > > > > > > > >
> > > > > > > > > > > > Is this makeRequest preloaded or not?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > <Preload> is already in the spec (and tied to
> > > > > makeRequest) -- the
> > > > > > only
> > > > > > > > change Louis is proposing is allowing authentication
> > > > > (something which
> > > > > > has
> > > > > > > > been shown to be necessary by most containers). This
> > > > > functionality is
> > > > > > purely
> > > > > > > > an optimization.
> > > > > > > > > > >
> > > > > > > > > > > The need for redundancy is ugly, but I don't see any
> > > > > other way to
> > > > > > do
> > > > > > > > it without making backwards compatibility very difficult.
> > > > > Under Louis
> > > > > > > > proposed model, a gadget server that didn't support
> > > > > <Preload> would
> > > > > > still
> > > > > > > > work with the gadget, which seems like a pretty big
> > > > > advantage to me,
> > > > > > though
> > > > > > > > we would probably want to be explicit and require that the
> > > > > authz used
> > > > > > > > between <Preload> and makeRequest be identical.
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > ~Kevin
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > ~Kevin
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ~Kevin
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>
Re: Proposal : Modify gadget spec to allow for authenticated/signed preloads & allow preloads to be defined per Content section.
Posted by Kevin Brown <et...@google.com>.
On Thu, May 1, 2008 at 7:15 PM, Louis Ryan <lr...@google.com> wrote:
> I'd like to propose some amendments to this spec, possibly for 0.8 if
> people are willing but if not at least for experimental inclusion in Shindig
> in short-order.
>
> 1. Add support for a 'view' attribute which identifies when a Preload
> should be executed based on which content sections are rendered. This is to
> allow for different preloads on different views. The value of the attribute
> is a comma-separated list of views. If the attributes is omitted the preload
> is always executed
>
> 2. Add support for a new authentication mode. SIGNED_OWNER_ONLY. In this
> situation the viewer information is omitted from the signed request. This is
> useful when the information returned by the backend does not care about the
> viewer. A concrete example is a profile view which is non-interactive but
> shows content that is entirely contextual to the owner. Omitting the viewer
> from requests for this kind of information allows for significantly better
> caching throughout the stack Containers which do not implement this mode can
> fallback to SIGNED.
Is a new auth mode really the right thing here? Why not authz="signed"
user="(owner | viewer | both)".
>
>
> Thoughts?
>
> -Louis
>
>
>
>
> On Thu, Apr 24, 2008 at 8:44 AM, Cassie <do...@google.com> wrote:
>
> > +1
> >
> > Okay, so Louis, Brian Eaton, Reinoudm and I are +1s and I think Kevin is
> > a +1.
> > As long as there aren't any objections this will go into 0.8
> >
> > - Cassie
> >
> >
> >
> >
> > On Mon, Apr 21, 2008 at 11:46 PM, Kevin Brown <et...@google.com> wrote:
> >
> > > On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <be...@google.com>
> > > wrote:
> > >
> > > >
> > > > So long as we're clear in the spec about what is supposed to happen
> > > > if
> > > > a preload is done for GET http://something, and then the gadget does
> > > > POST http://something instead. Those are different requests, a
> > > > preload for one should not impact the other.
> > >
> > >
> > > Just changing the verb is one thing, but actually attaching a post
> > > body here seems really bizarre.
> > >
> > >
> > > >
> > > > Doing preloads only for GET requests sounds reasonable.
> > > >
> > > > On Mon, Apr 21, 2008 at 9:58 AM, Louis Ryan <lr...@google.com>
> > > > wrote:
> > > > > For the moment just authz, if people have strong feelings about
> > > > method,
> > > > > post-body etc Im fine to adjust.
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 21, 2008 at 7:41 AM, Brian Eaton <be...@google.com>
> > > > wrote:
> > > > >
> > > > > >
> > > > > > I read the proposal differently. Any parameter that can be
> > > > passed to
> > > > > > makeRequest (HTTP, method, post body, etc...) should be an
> > > > optional
> > > > > > attribute for Preload as well. Or is that not what Louis was
> > > > trying
> > > > > > to say?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 21, 2008 at 4:33 AM, Cassie <do...@google.com> wrote:
> > > > > > > So, to be clear, the only spec change here is to add the
> > > > "authz"
> > > > > attribute
> > > > > > > to the "Preload" element, which would be interpreted as Louis
> > > > described
> > > > > > > above.
> > > > > > >
> > > > > > > Thanks.
> > > > > > > - Cassie
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Apr 15, 2008 at 12:56 PM, Kevin Brown <
> > > > etnu@google.com> wrote:
> > > > > > > >
> > > > > > > > On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst <
> > > > reinoud@hyves.nl>
> > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > + 1 on the theoretical side, especially since containers
> > > > don't have
> > > > > to
> > > > > > > support the preload (and everything will still work, although
> > > > with some
> > > > > more
> > > > > > > latency)
> > > > > > > > >
> > > > > > > > > On the practical side: I don't think that the st is sent
> > > > to shindig
> > > > > at
> > > > > > > the moment, so preloading a signed request may be difficult.
> > > > We
> > > > > shouldn't
> > > > > > > confuse spec with practical implementation though.
> > > > > > > >
> > > > > > > >
> > > > > > > > This is an implementation detail that is easily remedied.
> > > > The security
> > > > > > > token solution used by shindig is similar, if not identical,
> > > > to that
> > > > > used by
> > > > > > > other implementations, but it still remains just an
> > > > implementation
> > > > > detail.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > Something else: Can we assume that all preloaded content
> > > > at least
> > > > > allow
> > > > > > > caching during the lifetime of that single gadget instance? It
> > > > wouldn't
> > > > > make
> > > > > > > much sense to preload something that has a no-cache
> > > > directive...
> > > > > > > >
> > > > > > > >
> > > > > > > > I don't see that as being incompatible. Preloading something
> > > > that
> > > > > isn't
> > > > > > > cacheable just means that I have to take care to refetch it
> > > > every gadget
> > > > > > > render. Not ideal, certainly, but if the gadget author would
> > > > be doing a
> > > > > > > makeRequest anyway, it's a lot better to incur that latency
> > > > during the
> > > > > > > preload in most cases than it is to incur it after the gadget
> > > > has been
> > > > > > > rendered.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Apr 15, 2008 at 2:38 AM, Kevin Brown <
> > > > etnu@google.com>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden <
> > > > bruno@google.com>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > There's some redundancy here because both the Preload
> > > > and the
> > > > > > > io.makeRequest have to specify a signed fetch. Is there any
> > > > way to avoid
> > > > > > > this redundancy? Along those lines, what happens if the
> > > > Preload is
> > > > > signed
> > > > > > > but not the makeRequest? An author could easily try to do a
> > > > preload and
> > > > > yet
> > > > > > > have it fail for simple reasons.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > <Preload href="http://www.myhost.com/getdata"
> > > > authz="signed" />
> > > > > > > > > > >
> > > > > > > > > > > The content of a Preload request is made available to
> > > > the gadget
> > > > > > > developer by making the equivalent gadgets.io.makeRequest call
> > > > on the
> > > > > > > browser without making a remote call. E.g.
> > > > > > > > > > >
> > > > > > > > > > > var params = {}; // forgot "SIGNED" param
> > > > > > > > > > >
> > > > > > > > > > > gadgets.io.makeRequest("http://www.myhost.com/getdata
> > > > ",
> > > > > callback,
> > > > > > > params);
> > > > > > > > > > >
> > > > > > > > > > > Is this makeRequest preloaded or not?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > <Preload> is already in the spec (and tied to
> > > > makeRequest) -- the
> > > > > only
> > > > > > > change Louis is proposing is allowing authentication
> > > > (something which
> > > > > has
> > > > > > > been shown to be necessary by most containers). This
> > > > functionality is
> > > > > purely
> > > > > > > an optimization.
> > > > > > > > > >
> > > > > > > > > > The need for redundancy is ugly, but I don't see any
> > > > other way to
> > > > > do
> > > > > > > it without making backwards compatibility very difficult.
> > > > Under Louis
> > > > > > > proposed model, a gadget server that didn't support <Preload>
> > > > would
> > > > > still
> > > > > > > work with the gadget, which seems like a pretty big advantage
> > > > to me,
> > > > > though
> > > > > > > we would probably want to be explicit and require that the
> > > > authz used
> > > > > > > between <Preload> and makeRequest be identical.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > ~Kevin
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > ~Kevin
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > ~Kevin
> > >
> > >
> >
> >
> >
>
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to
> opensocial-and-gadgets-spec@googlegroups.com
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec-unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>