flj wrote: > > As for Thron7's idea of passing the session info as arguments, I have to > disagree. Authentication/Authorization is usually a process orthogonal to > the actual business logic that you want to call. Passing info needed for > authentication and authorization as arguments would require an additional, > intermediate layer, which recodes arguments for the actual business method > call. Best way is to have an out-of-band way of passing this additional > info, and not have it interfere with the actual call. > > At best, you could pass a structure/map containing the actual call > arguments in one key and the session info in another, and have a simple, > generic implementation for this additional layer which just passes only > the arguments key as arguments to the business logic method. But if you do > it as we do it, i.e. using a servlet filter for authentication and an > aspect for authorization, and wiring everything together via a spring > application context, this still isn't a solution - neither the aspect nor > the servlet filter are aware of the format of the call, and we don't want > to have either of them inspect the call arguments. >
Actually, I was also suprised about Thomas view in this matter. Unless you use aspect-oriented programming style, which woudl be able to insert the authentication logic automatically before calling the service method, the right place for keeping authentication state is the server, not the indivdidual service method. It would seem to me that extending each service method signature with authentication data (or other meta-information) and having to call the authentication procedure within each individual service method leads to unwanted code duplication. And what if the authentication scheme changes? You would have to update each and every single service method. That doesn't seem right. C. -- View this message in context: http://qooxdoo.678.n2.nabble.com/Rewriting-the-JSON-RPC-layer-compatibility-issues-tp5346941p5354189.html Sent from the qooxdoo mailing list archive at Nabble.com. ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
