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