On Fri, Dec 5, 2008 at 5:07 PM, Henning P. Schmiedehausen < [EMAIL PROTECTED]> wrote:
> Adam Winer <[EMAIL PROTECTED]> writes: > > >> > 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}</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.) > > That is not an oddity, this is a design flaw. > > - *If* the appId in the secure token and the appId in the method can > be different, then the semantics must be defined so that backends > can implement policy around it and know how to deal with it. This is the correct choice of the three you list. I agree the Javadoc could be improved to make the semantics more obvious. -- Adam > > > - *If* they never can be different but must be present in the REST URL, > then the REST API must make sure that they match and refuse service > otherwise. Backends should never have to deal with it. > > - *If* they never can be different, it would also make sense to > discuss whether they can go from the URLs and if yes, how. > > But this is an obvious implementation gotcha (implementors just use > the appId parameter to select the application data instead of using > the value from the token, thus opening their data wide to any > attacker) and calling it an "occasional oddity" is IMHO rude to > Shindig users. > > 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 >
