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