On 10 Nov, 2005, at 6:37 pm, p wrote:
1. One of the things I find problematic with cherrypy and Identity is
that they couple session management with cookies.
Paul, much of my own work is Ajaxy. Therefore, I'm keenly interested
in removing the need for cookies. What I'm thinking is also
implementing HTTP Auth (Basic & Digest). This would allow
XMLHttpRequest and XML-RPC clients to play in the identity framework
world.
I'm well aware that there is an existing implementation of HTTP Auth
for CherryPy and I'll be looking closely at that to see what can be
either reused or inspirational.
2. I also find the coupling of session management with auth schemes
problematic.
Actually the identity session is really entirely separate from the
standard session mechanism provided by CherryPy. The framework
doesn't actually store any user data. Because of scalability
concerns, I chose to place the burden of storage on the browser. As a
result, the framework reconstructs your identity information on each
request. (Now it would be ideal if SQLObject cached entities based on
alternate IDs to reduce the number of SQL queries, but reducing
queries doesn't seem to be a driving factor in the development of
SQLObject.)
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.
The latest version of the framework *looks* for groups and
permissions, but if they aren't present doesn't worry about it. If
you consider the framework carefully, it really *is* broken into two
parts: the identity filter and the authorisation code.
I could probably make the separation a little more explicit, but I'm
not certain what the benefit would be.
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.
Um... this changed some time ago. At the risk of increasing the
surface area of the default SQLObject model, I added a SecretToken
entity. A reasonably unique secret token is generated each time you
authenticate.
There have been requests to provide a means to generate a new
SecretToken for each request. I'm not certain how important that is
for 1.0 functionality (some feedback here would be helpful). In
addition, at least one person has asked that the visitor's IP address
be encoded in the signed portion of the cookie for an additional
level of security.
4. Finally, why the heck is everything stuffed into an init file?
ewwwww. :-)
I'm not certain exactly what you mean by this. It seems to be
standard CherryPy behaviour to configure filters and other stuff
through the config file. At last count there were 16 different
configuration options for the identity framework. Would you *really*
prefer specifying them as part of a constructor or something?
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.
Absolutely. I'm really delighted when developers take the time to
really dive into the code. Furthermore, I'm glad my relative newbie
status with Python isn't detracting too much from the quality.
Jeff
--
Jeff Watkins
http://newburyportion.com/
'I know about people who talk about suffering for the common good.
It's never bloody them! When you hear a man shouting "Forward, brave
comrades!" you'll see he's the one behind the bloody big rock and the
one wearing the only really arrow-proof helmet!'
-- Rincewind gives a speech on politics. (Terry Pratchett,
Interesting Times)
