After spending some time looking at cherrypy's implementation of sessions, as well as, Jeff Watkin's Identity Management, I thought I might share some questions/concerns. First off, I'd like to thank Jeff for throwing out the basic Identity framework. Strong work and much thanks. Now, on to the issues:
1. One of the things I find problematic with cherrypy and Identity is that they couple session management with cookies. This is fine if the client is a browser, not so otherwise. Specifically, I'm thinking of XMLRPC (and SOAP) clients that need to maintain state. If I'm not mistaken, in those cases, cherrypy changes the data to appear as form data to the server. Since identity filter already makes a distinction between cookie and form data, and XMLRPC data is converted to appear as form data (not entirely sure of this though), would it make sense to generalize the interface so that the session is sent to and retrieved from the client via a user defined methodology (with multiple ways for the same server to send and retrieve session data depending on the client accessing the session)? 2. I also find the coupling of session management with auth schemes problematic. Now I realize that in order to implement identity, it meant creating a way to maintain state on the server side. But Cherrypy has a fairly flexible mechanism for mainting sessions in Ram, a flat file, or on a database. Wouldn't it be more practical to push for changes on cherrpy's implementation? After all, the point of turbogears is to utilize pre-existing technologies and their communities, not reinvent the wheel. 2. Everything I've read says that authentication and authorization should be decoupled; is there a reason Identity didn't do so here? What happens if I just want to use the authentication scheme, but not worry about permissions? For ease of use, it would be nice to configure and reference each separately. 3. The code currently uses one secret token for the entire lifetime of the identity provider and there is a note that it should create one token for each identity - I agree. Additionally, for those of us with high security needs (i.e., we're worried about someone intercepting a request), it would be nice if the token were updated upon each request by each identity, or even better yet, a key system (or at least the option to do this) that ensures any intercepted data can not be used to access a session. 4. Finally, why the heck is everything stuffed into an init file? ewwwww. :-) Anyway, I hope this was constructive criticism and didn't come across as endless bitching. I really do appreciate the work you all have put into this. -Paul
