Dirk may want to step in here, as he had plans for how the auth filter should mediate here. But the last explanation I got of the whole st= gadget security token on the url was that it was deprecated and should go away soon. This code should be removed from the java impl and others should not follow its lead here. It's also the case, as bob points out, that the auth context has a lot of variables and needs some 'internal resolution' within the auth processing filter(s)to happen before you can ask a question like, "what is the id of the 'viewer' so you can pass it back to the data access layer.
more info here https://issues.apache.org/jira/browse/SHINDIG-290 (the diagram i wrote is wrong as it assumes a the rest server would be sent a gadget security token.it shouldn't that token is only for communication between the container page and gadget server.) davep On Thu, Aug 14, 2008 at 4:37 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: > We could create strongly types security tokens to represent each of these > cases. The use of isXXX functions goes some way to achieving this but maybe > not far enough. There certainly needs to be more information in the API > specs about that various mappings. > On Thu, Aug 14, 2008 at 3:50 PM, Robert Evans <[EMAIL PROTECTED]> wrote: > >> It seems that these concepts should be given more of a first class >> status than just deduced from the populated fields. Maybe it's not a >> big issue, but I can imagine developers forgetting a field, and >> getting back different data than they expected. Also, it might be >> worth having this in a big matrix with the meaning of the OAuth >> parameters (which get translated into a SecurityToken by the >> AuthFilter), since there is so much overlap in domain. >> >> Bob >> >> On Thu, Aug 14, 2008 at 2:56 PM, Louis Ryan <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > Id like to propose that we define more tightly the semantics of the >> fields >> > on SecurityToken's and what consumers of its information should infer. >> The >> > security token basically carries viewer-id, owner-id and app-id as its >> three >> > fundamental pieces of data. >> > >> > I'd like to propose the following semantics for permutations of those >> > fields, some of which is just re-hashing what we already do >> > >> > *1. (app-id=<not set>, viewer-id=<not set>, owner-id=<not set>)* - This >> is >> > the case of anonymous access to the API. This would only be allowed to >> > access public resources. >> > >> > *2. (app-id=<some id>, viewer-id=<some id>, owner-id=<some-id>)* - This >> is >> > the common gadget rendering case where an application is allowed to make >> API >> > calls acting-on-behalf of the viewer who is the authenticated principal. >> > This token is typically quite a restrictive, for example this token may >> not >> > allow modification of the owner-id's AppData. >> > >> > *3. (app-id=<some id>, viewer-id=<not set>, owner-id=<not set>) *- The >> is >> > the case of a trusted third-party which can assert ownership of the >> > specified application. This token would typically grant greater access >> than >> > the prior one, e.g it may grant access to update the AppData for any user >> > that has granted permissions to the specified application. >> > >> > *4. (app-id=<not set>, viewer-id=<some id>, owner-id=<not set>)* - The >> is >> > the case of a call to the API authenticated as the viewer. This would be >> > common for desktop applications that ask users for user/pass to >> authenticate >> > calls on the API. This token may grant greater access to the users >> profile >> > information than any of the prior ones. >> > >> > It would make a certain amount of sense to codify each of these cases. >> > Currently 1 is defined as 'isAnonymous' in our interfaces. Potential >> names >> > for 2-4 are >> > >> > 2. isApplictionOnBehalfOfUser >> > 3. isApplication >> > 4. isAuthenticatedUser >> > >> > Thoughts? >> > >> > -Louis >> > >> >
