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 <[EMAIL PROTECTED]>
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
>
