That is an ACL policy check the container must enforce, just as it would if you passed a bogus person id. As with all things in the protocols its the responsibility of the implementor to ensure consistent ACLing. Shindig makes some of that easier by giving you security tokens but containers bear ultimate responsibility.
On Fri, Dec 5, 2008 at 5:15 PM, Henning P. Schmiedehausen < [EMAIL PROTECTED]> wrote: > Louis Ryan <[EMAIL PROTECTED]> writes: > > >Consider the situation where I as a user make an authenticated request to > >the API to read appdata in one of my installed gadgets. Its very likely > that > >the security token in this case will have no appId and yet you could > >reasonably argue that the user should be able to access the data. Hence > >appId is in the protocol. > > What stops me, as a malicious user, to put in any random appId? How > can the container check whether the request is valid or not? How is > "one of my installed gadgets" defined in that case? > > > Ciao > Henning > > -- > Henning P. Schmiedehausen - Palo Alto, California, U.S.A. > [EMAIL PROTECTED] "We're Germans and we use Unix. > [EMAIL PROTECTED] That's a combination of two demographic groups > known to have no sense of humour whatsoever." > -- Hanno Mueller, de.comp.os.unix.programming >
