You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by David Primmer <da...@gmail.com> on 2008/05/30 23:28:37 UTC
rest api's versus tokens, which wins?
I have a general question about token handling precidence in the Rest
api server. It appears that some of the information encoded into the
rest urls is also in the token. When getting a url like this for app
data /appdata/{uid}/@self/{aid} you'd normally think that putting
somehting into {uid} and {aid}, userid and appid would affect the
query on the backend data, but if the contents of the token override
anything in the url, you're basically turning the appdata service into
an rpc endpoint called 'getAppDataForUser' and then passing in a
token. So what's the point of the rest service here?
Is the rule that the url semantics are there for when oauth is used?
Seems like these values are also intended to be encoded in a custom
oauth header. So what's the deal here? Should the url drive the query
composition and be verified by the token and throw an error if the two
don't match? Should the server ignore the elements in the url favoring
the token?
thanks.
davep
Re: rest api's versus tokens, which wins?
Posted by Kevin Brown <et...@google.com>.
On Mon, Jun 2, 2008 at 1:48 PM, David Primmer <da...@gmail.com>
wrote:
> Would it be too much to bring up the issue of versioning Shindig so
> that we don't have to do these types of things in the source tree?
> Implementing what I see as two versions of the services in the same
> trunk works for our case, so I suppose I'd agree to this workaround
> (we need other changes to the service interfaces as well) but I'm sure
> there are others situations where developers are doing things like
> this. Maybe someone would like to propose a method to version the
> codebase so we can don't have to straddle .7 and .8 compliance in the
> same codebase? It will have to happen eventually.
I talked about this a bit at I/O, and proposed branching / freezing once we
had 0.8 compliance; nobody really seemed to express an opinion one way or
another, other than expressing a desire for getting stable, compatible
releases eventually.
Right now shindig isn't really 0.7 or 0.8, it's somewhere in between the
two. If you really limited apps to only stuff available in 0.7, you'd have a
platform that's of limited use (which is why we had the 0.8 changes in the
first place).
The obvious problem here is that almost everyone has to implement some of
the interfaces, but most will only be altered by a small minority of users.
Changing something that accesses app data or activities is certainly more
dangerous than changing a parser.
So, we probably should set some realistic goals for a release. I feel that
we'd be constraining ourselves to little benefit if we do this before 0.8 is
fully implemented, but I'm certainly open to arguments on the contrary.
Individual artifacts can be frozen at different times so long as they remain
compatible with one another at all times.
>
> davep
>
> On Mon, Jun 2, 2008 at 1:36 PM, Cassie <do...@apache.org> wrote:
> > Ah, I understand the bug you filed much better now Dave. So, in the js
> apis
> > you aren't currently allowed to say which app the data is coming from.
> This
> > is why the service apis have the app id specified through the token. So,
> we
> > can definitely change this, but we will probably want to branch the
> service
> > interfaces - we may finally be at a point where this is necessary.
> >
> > So, I think we should create three new interfaces for the rest services -
> > and then we will have the Basic*Service impls just implement both the
> json
> > interfaces and the rest interfaces. Later on, we can remove the
> deprecated
> > json stuff when restful is sufficient as a replacement.
> >
> > What do ya think?
> >
> > - Cassie
> >
> >
> > On Mon, Jun 2, 2008 at 8:20 AM, Louis Ryan <lr...@google.com> wrote:
> > This restriction makes it difficult to provide services for a viewer for
> > which the container does not want to expose an ID such as a request for
> > permissions. we may need to consider an extended syntax to refer to the
> > viewer and owner in an auth token as part of the projection (@viewer
> @owner
> > ?)
> > On an unrelated note it seems order of the appdata url parts is
> backwards.
> > Based on the premise that removing elements of the path continues to make
> > the URL useful I dont see much use for
> >
> > /appdata/{guid} --Fetching data across a set of applications for a
> single
> > user
> >
> > whereas
> >
> > /appdata/{appid} -- Fetching data across a set of users for a single
> > application.
> >
> > seems much more likely. The former case will almost certainly be
> completely
> > disallowed for ACL reasons but the latter can be used by an application
> > backend to read data from its installed user base.
> >
> > On Fri, May 30, 2008 at 3:30 PM, David Primmer <da...@gmail.com>
> > wrote:
> >
> >> Sticking to "token is only auth context" helps as a general rule.
> >> That means all variables in the url win as far as selecting the data
> >> to be operated on and id's from tokens are used only in ACL checks.
> >>
> >> There are exceptions to this and I hope in the future we can augment
> >> the current url patterns with full auth-aware projections that are a
> >> combination of acl and query for those that want to be explicit.
> >> Google calendar does something like this with the full and basic
> >> projections. Your token will give you the projection you have rights
> >> to if you don't specify it, but at least it is possible to ask for
> >> more data than you should see and get denied.
> >>
> >> This means all the data interfaces need to be able to take these
> >> variables as parameters and not expect info to be slipped through in
> >> the token. The DataService.java and BasicDataService are examples of
> >> components in need of upgrades.
> >>
> >> davep
> >>
> >> On Fri, May 30, 2008 at 3:02 PM, Kevin Brown <et...@google.com> wrote:
> >> > It would seem to me that the url param should always win, but you
> still
> >> need
> >> > data from the token to make it all make sense in the first place
> (@self,
> >> for
> >> > instance).
> >> >
> >> > app id should probably always be derived from the url (assuming it's
> an
> >> app
> >> > data-centric call, of course). App ids are public.
> >> >
> >> > The real question here is -- can any arbitrary app request data from
> >> another
> >> > app? Is it ok for appid "foo" to get data for appid "bar"? I believe
> the
> >> > answer here is "yes", in which case the appid passed in the security
> >> > credentials is simply used to identify the source of the request,
> *not*
> >> the
> >> > target of the operation (this is generally true for all fields in the
> >> > tokens).
> >> >
> >> > On Fri, May 30, 2008 at 2:28 PM, David Primmer <
> david.primmer@gmail.com>
> >> > wrote:
> >> >
> >> >> I have a general question about token handling precidence in the Rest
> >> >> api server. It appears that some of the information encoded into the
> >> >> rest urls is also in the token. When getting a url like this for app
> >> >> data /appdata/{uid}/@self/{aid} you'd normally think that putting
> >> >> somehting into {uid} and {aid}, userid and appid would affect the
> >> >> query on the backend data, but if the contents of the token override
> >> >> anything in the url, you're basically turning the appdata service
> into
> >> >> an rpc endpoint called 'getAppDataForUser' and then passing in a
> >> >> token. So what's the point of the rest service here?
> >> >>
> >> >> Is the rule that the url semantics are there for when oauth is used?
> >> >> Seems like these values are also intended to be encoded in a custom
> >> >> oauth header. So what's the deal here? Should the url drive the query
> >> >> composition and be verified by the token and throw an error if the
> two
> >> >> don't match? Should the server ignore the elements in the url
> favoring
> >> >> the token?
> >> >>
> >> >> thanks.
> >> >>
> >> >> davep
> >> >>
> >> >
> >>
> >
>
Re: rest api's versus tokens, which wins?
Posted by David Primmer <da...@gmail.com>.
Would it be too much to bring up the issue of versioning Shindig so
that we don't have to do these types of things in the source tree?
Implementing what I see as two versions of the services in the same
trunk works for our case, so I suppose I'd agree to this workaround
(we need other changes to the service interfaces as well) but I'm sure
there are others situations where developers are doing things like
this. Maybe someone would like to propose a method to version the
codebase so we can don't have to straddle .7 and .8 compliance in the
same codebase? It will have to happen eventually.
davep
On Mon, Jun 2, 2008 at 1:36 PM, Cassie <do...@apache.org> wrote:
> Ah, I understand the bug you filed much better now Dave. So, in the js apis
> you aren't currently allowed to say which app the data is coming from. This
> is why the service apis have the app id specified through the token. So, we
> can definitely change this, but we will probably want to branch the service
> interfaces - we may finally be at a point where this is necessary.
>
> So, I think we should create three new interfaces for the rest services -
> and then we will have the Basic*Service impls just implement both the json
> interfaces and the rest interfaces. Later on, we can remove the deprecated
> json stuff when restful is sufficient as a replacement.
>
> What do ya think?
>
> - Cassie
>
>
> On Mon, Jun 2, 2008 at 8:20 AM, Louis Ryan <lr...@google.com> wrote:
> This restriction makes it difficult to provide services for a viewer for
> which the container does not want to expose an ID such as a request for
> permissions. we may need to consider an extended syntax to refer to the
> viewer and owner in an auth token as part of the projection (@viewer @owner
> ?)
> On an unrelated note it seems order of the appdata url parts is backwards.
> Based on the premise that removing elements of the path continues to make
> the URL useful I dont see much use for
>
> /appdata/{guid} --Fetching data across a set of applications for a single
> user
>
> whereas
>
> /appdata/{appid} -- Fetching data across a set of users for a single
> application.
>
> seems much more likely. The former case will almost certainly be completely
> disallowed for ACL reasons but the latter can be used by an application
> backend to read data from its installed user base.
>
> On Fri, May 30, 2008 at 3:30 PM, David Primmer <da...@gmail.com>
> wrote:
>
>> Sticking to "token is only auth context" helps as a general rule.
>> That means all variables in the url win as far as selecting the data
>> to be operated on and id's from tokens are used only in ACL checks.
>>
>> There are exceptions to this and I hope in the future we can augment
>> the current url patterns with full auth-aware projections that are a
>> combination of acl and query for those that want to be explicit.
>> Google calendar does something like this with the full and basic
>> projections. Your token will give you the projection you have rights
>> to if you don't specify it, but at least it is possible to ask for
>> more data than you should see and get denied.
>>
>> This means all the data interfaces need to be able to take these
>> variables as parameters and not expect info to be slipped through in
>> the token. The DataService.java and BasicDataService are examples of
>> components in need of upgrades.
>>
>> davep
>>
>> On Fri, May 30, 2008 at 3:02 PM, Kevin Brown <et...@google.com> wrote:
>> > It would seem to me that the url param should always win, but you still
>> need
>> > data from the token to make it all make sense in the first place (@self,
>> for
>> > instance).
>> >
>> > app id should probably always be derived from the url (assuming it's an
>> app
>> > data-centric call, of course). App ids are public.
>> >
>> > The real question here is -- can any arbitrary app request data from
>> another
>> > app? Is it ok for appid "foo" to get data for appid "bar"? I believe the
>> > answer here is "yes", in which case the appid passed in the security
>> > credentials is simply used to identify the source of the request, *not*
>> the
>> > target of the operation (this is generally true for all fields in the
>> > tokens).
>> >
>> > On Fri, May 30, 2008 at 2:28 PM, David Primmer <da...@gmail.com>
>> > wrote:
>> >
>> >> I have a general question about token handling precidence in the Rest
>> >> api server. It appears that some of the information encoded into the
>> >> rest urls is also in the token. When getting a url like this for app
>> >> data /appdata/{uid}/@self/{aid} you'd normally think that putting
>> >> somehting into {uid} and {aid}, userid and appid would affect the
>> >> query on the backend data, but if the contents of the token override
>> >> anything in the url, you're basically turning the appdata service into
>> >> an rpc endpoint called 'getAppDataForUser' and then passing in a
>> >> token. So what's the point of the rest service here?
>> >>
>> >> Is the rule that the url semantics are there for when oauth is used?
>> >> Seems like these values are also intended to be encoded in a custom
>> >> oauth header. So what's the deal here? Should the url drive the query
>> >> composition and be verified by the token and throw an error if the two
>> >> don't match? Should the server ignore the elements in the url favoring
>> >> the token?
>> >>
>> >> thanks.
>> >>
>> >> davep
>> >>
>> >
>>
>
Re: rest api's versus tokens, which wins?
Posted by Cassie <do...@apache.org>.
Ah, I understand the bug you filed much better now Dave. So, in the js apis
you aren't currently allowed to say which app the data is coming from. This
is why the service apis have the app id specified through the token. So, we
can definitely change this, but we will probably want to branch the service
interfaces - we may finally be at a point where this is necessary.
So, I think we should create three new interfaces for the rest services -
and then we will have the Basic*Service impls just implement both the json
interfaces and the rest interfaces. Later on, we can remove the deprecated
json stuff when restful is sufficient as a replacement.
What do ya think?
- Cassie
On Mon, Jun 2, 2008 at 8:20 AM, Louis Ryan <lr...@google.com> wrote:
This restriction makes it difficult to provide services for a viewer for
which the container does not want to expose an ID such as a request for
permissions. we may need to consider an extended syntax to refer to the
viewer and owner in an auth token as part of the projection (@viewer @owner
?)
On an unrelated note it seems order of the appdata url parts is backwards.
Based on the premise that removing elements of the path continues to make
the URL useful I dont see much use for
/appdata/{guid} --Fetching data across a set of applications for a single
user
whereas
/appdata/{appid} -- Fetching data across a set of users for a single
application.
seems much more likely. The former case will almost certainly be completely
disallowed for ACL reasons but the latter can be used by an application
backend to read data from its installed user base.
On Fri, May 30, 2008 at 3:30 PM, David Primmer <da...@gmail.com>
wrote:
> Sticking to "token is only auth context" helps as a general rule.
> That means all variables in the url win as far as selecting the data
> to be operated on and id's from tokens are used only in ACL checks.
>
> There are exceptions to this and I hope in the future we can augment
> the current url patterns with full auth-aware projections that are a
> combination of acl and query for those that want to be explicit.
> Google calendar does something like this with the full and basic
> projections. Your token will give you the projection you have rights
> to if you don't specify it, but at least it is possible to ask for
> more data than you should see and get denied.
>
> This means all the data interfaces need to be able to take these
> variables as parameters and not expect info to be slipped through in
> the token. The DataService.java and BasicDataService are examples of
> components in need of upgrades.
>
> davep
>
> On Fri, May 30, 2008 at 3:02 PM, Kevin Brown <et...@google.com> wrote:
> > It would seem to me that the url param should always win, but you still
> need
> > data from the token to make it all make sense in the first place (@self,
> for
> > instance).
> >
> > app id should probably always be derived from the url (assuming it's an
> app
> > data-centric call, of course). App ids are public.
> >
> > The real question here is -- can any arbitrary app request data from
> another
> > app? Is it ok for appid "foo" to get data for appid "bar"? I believe the
> > answer here is "yes", in which case the appid passed in the security
> > credentials is simply used to identify the source of the request, *not*
> the
> > target of the operation (this is generally true for all fields in the
> > tokens).
> >
> > On Fri, May 30, 2008 at 2:28 PM, David Primmer <da...@gmail.com>
> > wrote:
> >
> >> I have a general question about token handling precidence in the Rest
> >> api server. It appears that some of the information encoded into the
> >> rest urls is also in the token. When getting a url like this for app
> >> data /appdata/{uid}/@self/{aid} you'd normally think that putting
> >> somehting into {uid} and {aid}, userid and appid would affect the
> >> query on the backend data, but if the contents of the token override
> >> anything in the url, you're basically turning the appdata service into
> >> an rpc endpoint called 'getAppDataForUser' and then passing in a
> >> token. So what's the point of the rest service here?
> >>
> >> Is the rule that the url semantics are there for when oauth is used?
> >> Seems like these values are also intended to be encoded in a custom
> >> oauth header. So what's the deal here? Should the url drive the query
> >> composition and be verified by the token and throw an error if the two
> >> don't match? Should the server ignore the elements in the url favoring
> >> the token?
> >>
> >> thanks.
> >>
> >> davep
> >>
> >
>
Re: rest api's versus tokens, which wins?
Posted by Louis Ryan <lr...@google.com>.
This restriction makes it difficult to provide services for a viewer for
which the container does not want to expose an ID such as a request for
permissions. we may need to consider an extended syntax to refer to the
viewer and owner in an auth token as part of the projection (@viewer @owner
?)
On an unrelated note it seems order of the appdata url parts is backwards.
Based on the premise that removing elements of the path continues to make
the URL useful I dont see much use for
/appdata/{guid} --Fetching data across a set of applications for a single
user
whereas
/appdata/{appid} -- Fetching data across a set of users for a single
application.
seems much more likely. The former case will almost certainly be completely
disallowed for ACL reasons but the latter can be used by an application
backend to read data from its installed user base.
On Fri, May 30, 2008 at 3:30 PM, David Primmer <da...@gmail.com>
wrote:
> Sticking to "token is only auth context" helps as a general rule.
> That means all variables in the url win as far as selecting the data
> to be operated on and id's from tokens are used only in ACL checks.
>
> There are exceptions to this and I hope in the future we can augment
> the current url patterns with full auth-aware projections that are a
> combination of acl and query for those that want to be explicit.
> Google calendar does something like this with the full and basic
> projections. Your token will give you the projection you have rights
> to if you don't specify it, but at least it is possible to ask for
> more data than you should see and get denied.
>
> This means all the data interfaces need to be able to take these
> variables as parameters and not expect info to be slipped through in
> the token. The DataService.java and BasicDataService are examples of
> components in need of upgrades.
>
> davep
>
> On Fri, May 30, 2008 at 3:02 PM, Kevin Brown <et...@google.com> wrote:
> > It would seem to me that the url param should always win, but you still
> need
> > data from the token to make it all make sense in the first place (@self,
> for
> > instance).
> >
> > app id should probably always be derived from the url (assuming it's an
> app
> > data-centric call, of course). App ids are public.
> >
> > The real question here is -- can any arbitrary app request data from
> another
> > app? Is it ok for appid "foo" to get data for appid "bar"? I believe the
> > answer here is "yes", in which case the appid passed in the security
> > credentials is simply used to identify the source of the request, *not*
> the
> > target of the operation (this is generally true for all fields in the
> > tokens).
> >
> > On Fri, May 30, 2008 at 2:28 PM, David Primmer <da...@gmail.com>
> > wrote:
> >
> >> I have a general question about token handling precidence in the Rest
> >> api server. It appears that some of the information encoded into the
> >> rest urls is also in the token. When getting a url like this for app
> >> data /appdata/{uid}/@self/{aid} you'd normally think that putting
> >> somehting into {uid} and {aid}, userid and appid would affect the
> >> query on the backend data, but if the contents of the token override
> >> anything in the url, you're basically turning the appdata service into
> >> an rpc endpoint called 'getAppDataForUser' and then passing in a
> >> token. So what's the point of the rest service here?
> >>
> >> Is the rule that the url semantics are there for when oauth is used?
> >> Seems like these values are also intended to be encoded in a custom
> >> oauth header. So what's the deal here? Should the url drive the query
> >> composition and be verified by the token and throw an error if the two
> >> don't match? Should the server ignore the elements in the url favoring
> >> the token?
> >>
> >> thanks.
> >>
> >> davep
> >>
> >
>
Re: GadgetSpec serializable ?
Posted by Louis Ryan <lr...@google.com>.
I think this is a general issue with different caching services in Java,
many of which require objects to be serializable. As Kevin says patches with
tests are welcome :)
On Tue, Jun 3, 2008 at 6:34 PM, Kevin Brown <et...@google.com> wrote:
> On Mon, Jun 2, 2008 at 10:31 PM, Viji Subramanian <
> Viji.Subramanian@corp.aol.com> wrote:
>
> > I am looking at caching the gadgetSpec so that we can avoid the expensive
> > Xml Parsing everytime the gadget manifest is fetched [either remote /
> from
> > cache]. I see that most of the fields in gadget spec are private - and
> it
> > doesn't implement serializable.. So, i am pretty much left with java
> > reflection if I want to serialize gadgetSpec. which would then involve
> > extending the same technique for all other objects like ModulePref,
> UserPref
> > etc..
>
>
> The specs themselves are pretty trivially cached in memory (the default
> implementation uses an LRU cache). Retrieval of remote files (including
> gadget specs) is done by implementing HttpCache. Are you really gaining
> anything by remotely caching the parsed gadget specs?
>
>
> > Are there any plans to make the gadgetSpec and related classes implement
> > Serializable.. ?
> > Any other suggestions.. or thoughts around this ? ..
>
>
> Patches are always welcome :)
>
>
> >
> >
> > Thanks
> >
> >
> > Kevin Brown wrote:
> >
> >> The simple answer is that we haven't yet had any real need to serialize
> it
> >> (though some caching implementations might benefit from this).
> >>
> >> On Fri, May 30, 2008 at 3:42 PM, Viji Subramanian <
> >> Viji.Subramanian@corp.aol.com> wrote:
> >>
> >>
> >>
> >>> Is there a reason why GadgetSpec is not serializable ? why doesn't it
> >>> implement serializable ?
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>
Re: GadgetSpec serializable ?
Posted by Kevin Brown <et...@google.com>.
On Mon, Jun 2, 2008 at 10:31 PM, Viji Subramanian <
Viji.Subramanian@corp.aol.com> wrote:
> I am looking at caching the gadgetSpec so that we can avoid the expensive
> Xml Parsing everytime the gadget manifest is fetched [either remote / from
> cache]. I see that most of the fields in gadget spec are private - and it
> doesn't implement serializable.. So, i am pretty much left with java
> reflection if I want to serialize gadgetSpec. which would then involve
> extending the same technique for all other objects like ModulePref, UserPref
> etc..
The specs themselves are pretty trivially cached in memory (the default
implementation uses an LRU cache). Retrieval of remote files (including
gadget specs) is done by implementing HttpCache. Are you really gaining
anything by remotely caching the parsed gadget specs?
> Are there any plans to make the gadgetSpec and related classes implement
> Serializable.. ?
> Any other suggestions.. or thoughts around this ? ..
Patches are always welcome :)
>
>
> Thanks
>
>
> Kevin Brown wrote:
>
>> The simple answer is that we haven't yet had any real need to serialize it
>> (though some caching implementations might benefit from this).
>>
>> On Fri, May 30, 2008 at 3:42 PM, Viji Subramanian <
>> Viji.Subramanian@corp.aol.com> wrote:
>>
>>
>>
>>> Is there a reason why GadgetSpec is not serializable ? why doesn't it
>>> implement serializable ?
>>>
>>>
>>>
>>
>>
>>
>
>
Re: GadgetSpec serializable ?
Posted by Viji Subramanian <Vi...@corp.aol.com>.
I am looking at caching the gadgetSpec so that we can avoid the
expensive Xml Parsing everytime the gadget manifest is fetched [either
remote / from cache]. I see that most of the fields in gadget spec are
private - and it doesn't implement serializable.. So, i am pretty much
left with java reflection if I want to serialize gadgetSpec. which
would then involve extending the same technique for all other objects
like ModulePref, UserPref etc..
Are there any plans to make the gadgetSpec and related classes implement
Serializable.. ?
Any other suggestions.. or thoughts around this ? ..
Thanks
Kevin Brown wrote:
> The simple answer is that we haven't yet had any real need to serialize it
> (though some caching implementations might benefit from this).
>
> On Fri, May 30, 2008 at 3:42 PM, Viji Subramanian <
> Viji.Subramanian@corp.aol.com> wrote:
>
>
>> Is there a reason why GadgetSpec is not serializable ? why doesn't it
>> implement serializable ?
>>
>>
>
>
Re: GadgetSpec serializable ?
Posted by Kevin Brown <et...@google.com>.
The simple answer is that we haven't yet had any real need to serialize it
(though some caching implementations might benefit from this).
On Fri, May 30, 2008 at 3:42 PM, Viji Subramanian <
Viji.Subramanian@corp.aol.com> wrote:
> Is there a reason why GadgetSpec is not serializable ? why doesn't it
> implement serializable ?
>
GadgetSpec serializable ?
Posted by Viji Subramanian <Vi...@corp.aol.com>.
Is there a reason why GadgetSpec is not serializable ? why doesn't it
implement serializable ?
Re: rest api's versus tokens, which wins?
Posted by David Primmer <da...@gmail.com>.
Sticking to "token is only auth context" helps as a general rule.
That means all variables in the url win as far as selecting the data
to be operated on and id's from tokens are used only in ACL checks.
There are exceptions to this and I hope in the future we can augment
the current url patterns with full auth-aware projections that are a
combination of acl and query for those that want to be explicit.
Google calendar does something like this with the full and basic
projections. Your token will give you the projection you have rights
to if you don't specify it, but at least it is possible to ask for
more data than you should see and get denied.
This means all the data interfaces need to be able to take these
variables as parameters and not expect info to be slipped through in
the token. The DataService.java and BasicDataService are examples of
components in need of upgrades.
davep
On Fri, May 30, 2008 at 3:02 PM, Kevin Brown <et...@google.com> wrote:
> It would seem to me that the url param should always win, but you still need
> data from the token to make it all make sense in the first place (@self, for
> instance).
>
> app id should probably always be derived from the url (assuming it's an app
> data-centric call, of course). App ids are public.
>
> The real question here is -- can any arbitrary app request data from another
> app? Is it ok for appid "foo" to get data for appid "bar"? I believe the
> answer here is "yes", in which case the appid passed in the security
> credentials is simply used to identify the source of the request, *not* the
> target of the operation (this is generally true for all fields in the
> tokens).
>
> On Fri, May 30, 2008 at 2:28 PM, David Primmer <da...@gmail.com>
> wrote:
>
>> I have a general question about token handling precidence in the Rest
>> api server. It appears that some of the information encoded into the
>> rest urls is also in the token. When getting a url like this for app
>> data /appdata/{uid}/@self/{aid} you'd normally think that putting
>> somehting into {uid} and {aid}, userid and appid would affect the
>> query on the backend data, but if the contents of the token override
>> anything in the url, you're basically turning the appdata service into
>> an rpc endpoint called 'getAppDataForUser' and then passing in a
>> token. So what's the point of the rest service here?
>>
>> Is the rule that the url semantics are there for when oauth is used?
>> Seems like these values are also intended to be encoded in a custom
>> oauth header. So what's the deal here? Should the url drive the query
>> composition and be verified by the token and throw an error if the two
>> don't match? Should the server ignore the elements in the url favoring
>> the token?
>>
>> thanks.
>>
>> davep
>>
>
Re: rest api's versus tokens, which wins?
Posted by Kevin Brown <et...@google.com>.
It would seem to me that the url param should always win, but you still need
data from the token to make it all make sense in the first place (@self, for
instance).
app id should probably always be derived from the url (assuming it's an app
data-centric call, of course). App ids are public.
The real question here is -- can any arbitrary app request data from another
app? Is it ok for appid "foo" to get data for appid "bar"? I believe the
answer here is "yes", in which case the appid passed in the security
credentials is simply used to identify the source of the request, *not* the
target of the operation (this is generally true for all fields in the
tokens).
On Fri, May 30, 2008 at 2:28 PM, David Primmer <da...@gmail.com>
wrote:
> I have a general question about token handling precidence in the Rest
> api server. It appears that some of the information encoded into the
> rest urls is also in the token. When getting a url like this for app
> data /appdata/{uid}/@self/{aid} you'd normally think that putting
> somehting into {uid} and {aid}, userid and appid would affect the
> query on the backend data, but if the contents of the token override
> anything in the url, you're basically turning the appdata service into
> an rpc endpoint called 'getAppDataForUser' and then passing in a
> token. So what's the point of the rest service here?
>
> Is the rule that the url semantics are there for when oauth is used?
> Seems like these values are also intended to be encoded in a custom
> oauth header. So what's the deal here? Should the url drive the query
> composition and be verified by the token and throw an error if the two
> don't match? Should the server ignore the elements in the url favoring
> the token?
>
> thanks.
>
> davep
>