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