On Feb 8, 2008 5:24 PM, Mark Ramm <[EMAIL PROTECTED]> wrote: > > > I've restarted my identity stuff, and I hope to have something vary > basic > > along with some clear notes by the time of the sprint, so that I (and > > interested others) can get this going. I agree that identity-management > is > > key to making life easier for the developer (which is kinda the point of > TG, > > IMO). > > > > Here's what I would like to see in a new identity-like package: > > - be able to use it everywhere you could in TG1 > > - cover the traditional user/group/permission model of auth handling > > - support HTTP basic/digest auth > > - support form-based auth > > - support OpenID (less important to me personally, but I know others > really > > want this feature) > > - support multiple methods of authentication info storage (DB, NTLM, > > .htaccess, LDAP, unix passwords, etc...) > > - support multiple methods of authorization info storage (DB, LDAP, > etc...) > > - make very extensible, so users can severely customize it if they want > (use > > setuptools!) > > - have sane, covers-90%-of-use-cases default configuration > > > > I think that covers it...good thing I'm not asking for much :) > > > > I'm really less concerned with making the API exactly like identity, > though > > I have no specific complaints about that API. > > Sounds good to me. > > I think the @require decorator and the predicite checking syntax are good. > > i would love to see user/group/permission stuff grabbed by the > identity middleware and put into the wsgi environ, so that the > decorators are just dependant on the identity key in the environ. > That will localize all of the provider customization in the > middleware, and I agree that need to be designed up front to work with > multiple backends. I also think it might be worthwhile offering an > option to cache all that information in the beaker session, so that > folks using Memcachd can avoid a database hit for users who are > already authenticated. But that's the kind of thing that we can grow > later. But I do think it totally reasonable to have identity depend > on beaker for "visit" like functionality if necessary. > > --Mark Ramm > > I've been thinking along the same lines. Some kind of session management piece is (IMO) definitely necessary, and since beaker is already there, that's what I was planning on using.
So when the user logs in, a "user object" is created and inserted in to the WSGI environ. The user object I had in mind looks something like this: user.name = <username> (or a default username that indicates noone has authenticated, like "anonymous") user.groups = <list of groups that this person is a member of> or None user.permissions = <list of permissions that this person has> or None now @require can just use this, and you can also use the user object inside your controller if need be. ...or if the user object approach isn't workable for some reason, you could put the above into separate wsgi environ vars, though I like the object approach better, personally. Perhaps even the user object could be pluggable, allowing users to create their own user objects. Most people shouldn't need this, but I'm sure it would be useful to some. Thoughts? Kevin Horn --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
