There is a big difference between "authentication" (making sure someone is who they claim to be) and "authorization" (making sure that now that we know who they are, they have permission to do what they're trying to do).
It seems to me that what you're referring to is a Role-Based Access Control (RBAC) system. And when you say "dynamic," I believe that what you mean is that you will keep users, roles, and permissions in a database where they can be easily changed rather than hard-coded in Lift. I could be wrong, but I am pretty sure that Lift offers no such system and you'll have to roll your own. I need to do this myself, and I'm interested in control down to individual properties and methods in system objects. So I'd be very interested in anything you (or anyone else) comes up with. Chas. glenn wrote: > Tim, > I tend to agree with you that the Role trait is not a good mixin for a > role mapper, which is why > I raise the question. > > Maybe I'm looking in the wrong place, but the http-authentication > example in liftweb.sites on github > doesn't have much code. The LiftBook is a more complete example. And > neither deals with useage > of the Role trait, nor with persisting authorization info. Is there > some other example I should be looking at? > > On the issue of dynamic auth, the examples I've seen all run in Boot > which leaves open > the question of how to manage the same thing on the fly, so to speak, > not that it can't be > done. You guys have done too good a job on Lift to have overlooked > that. > > Glenn... > > > > On Sep 4, 4:03 pm, Timothy Perrett <timo...@getintheloop.eu> wrote: >> Glenn, >> >> If Marius doesn't beat ne to it, I'll reply tomorrow morning. The >> system we implemented for auth was not meant to be composed with >> matter per-say, not in the way you think however... >> >> Presumably you've looked at the http Auth example in the github repo? >> I'm not sure why on earth you would think it's not possible to do >> dynamic auth with the existing system? Of course it is! >> >> Cheers >> >> Tim >> >> Sent from my iPhone >> >> On 4 Sep 2009, at 22:53, glenn <gl...@exmbly.com> wrote: >> >> >> >>> I'm looking for direction on the best pattern for implementing basic >>> authentication and authorization in Lift. >>> For example, if I already have a Role mapper to store roles in the >>> database, to what do I attach the Role trait in >>> the net.liftweb.http.auth package? >>> 1) The mapper. You would have to make sure there were no naming >>> conflicts ( i.e., def name in the trait and the mapped string, name, >>> in the mapper. Not the best design pattern to link the two, in my >>> humble opinion.) >>> or >>> 2) A new class, or perhaps an object, with the trait that wraps a Role >>> mapper instance. >>> The other piece to the puzzle is managing the list of AuthRoles, >>> create protected resources and build the Lift.authentication cases. If >>> you limit this to Boot, then you give up on dynamic authentication and >>> authorization, or do you? >>> Glenn... > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
