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.
On Fri, Dec 5, 2008 at 4:39 PM, Adam Winer <[EMAIL PROTECTED]> wrote: > On Fri, Dec 5, 2008 at 4:12 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > On Fri, Dec 5, 2008 at 4:09 PM, Henning P. Schmiedehausen > > <[EMAIL PROTECTED]> wrote: > > > Brian Eaton <[EMAIL PROTECTED]> writes: > > > > > >>On Fri, Dec 5, 2008 at 3:22 PM, Adam Winer <[EMAIL PROTECTED]> wrote: > > >>> AppDataService.updatePersonData() has a String appId parameter. An > > >>> implementation would, most likely, compare the appId here against > > >>> SecurityToken.getAppId(), and only permit updating if the two match, > > but > > >>> that's a container policy decision. > > > > > >>Ummm.... if there's only one sensible policy to implement...? > > > > > > Which would be? If the only sensible policy is to write to your own > > > application data, then why is there an appId parameter on the method? > > > > > > The backend can get the appId using token.getAppId() just fine, no > > > need for an additional method. > > > > I had exactly this question when I was looking at using appdata for user > > prefs. > > > > There's an appId on the method because there's appId in the REST URL: > > <Service> > <Type>http://ns.opensocial.org//2008/opensocial/appdata</Type> > <os:URI-Template> > http://api.example.org/appdata/{guid}/{appid}/{selector}<http://api.example.org/appdata/%7Bguid%7D/%7Bappid%7D/%7Bselector%7D> > </os:URI-Template> > </Service> > > And it needs to be in the REST URL because it's a different resource. > > Shindig could well have made a decision that no container will ever > support an appId other than the one in the token, but generally it > doesn't hide any of the flexibility in the URL (and IMO, the > occasional oddity like this is worth the consistency.) > > - Adam >

