On Fri, Sep 5, 2008 at 3:15 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 5, 2008 at 3:05 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > On Fri, Sep 5, 2008 at 2:49 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > >> For example, as far as the signed fetch > >> and OAuth code are concerned "" is a completely legitimate user id. > > > > > > Yes, and that legitimate id will map to the same user at all times, > > resulting in the same effect as if no auth was used at all. > > Not so. What will actually happen is that all users will be treated > as having the same identity. > > For example, if I use signed fetch to build up a list of my favorite > songs, the next person to login will see those same favorite songs. Only if the container isn't providing a security token. > > > And if I use OAuth to link my Shindig identity "" to my MySpace > identity, then the next person to visit will see my MySpace data. Only true if the storage system accepts empty values for both user id and app id. > > > Yes, that can really happen. There is nothing to prevent it. > > One hopes that someone would notice before they went live, but if the > site has authentication for most users, it could slip through QA. > > > Three legged oauth simply fails (no stored tokens for the anonymous > user). > > Unfortunately that isn't true today. How so? Where can I add an oauth token that works without an app id? > > > > API contracts that require the user to call a method are very error > prone. > > What we're stating here is that every single piece of code that ever > touches > > SecurityTokens (which is roughly 2/3rds of the code base) must call > > isAnonymous() before extracting any piece of data. That isn't happening > now > > (not by a long shot), and it's not likely going to happen either. > > Requiring != null is fine by me. > > Requiring isAnonymous I can live with, though I'm mildly annoyed by it. > > Requiring both would be a travesty of decency, and we would have to > ask for UN intervention. =) >
