Re: Proposal : Modify gadget spec to allow for authenticated/signed preloads & allow preloads to be defined per Content section.

[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
> -~----------~----~----~----~------~----~------~--~---
>
>