[Lift] Re: Using Roles and LIftRules.authentication
On Sep 8, 7:00 pm, glenn wrote:
> Marius,
>
> I guess there is little more to be said on this issue. Keep in mind
> that
> in many real-world applications, dynamically assigned user roles are a
> requirement. And it's possible for users to have multiple roles, each
> in a different role hierarchy, in the same application.
Well Lift Roles are build on hierarchical model.
>
> Inevitably, I will have to implement my own, perhaps using
> JaaS or one of its variants. If you have any thoughts on that issue,
> I'd like to hear them.
I kind of doubt that JAAS will take you farther then Lift HTTP auth
support.
>
> Thanks,
>
> Glenn
>
> On Sep 8, 8:40 am, "marius d." wrote:
>
> > On Sep 8, 6:12 pm, glenn wrote:
>
> > > Marius,
>
> > > With your help, I think I'm getting closer to understanding what is
> > > needed
> > > here.
>
> > > One thing though, is that I believe I do need to manually check if the
> > > user has the
> > > appropriate role (in the DB) before I can set userRoles RequestVar.
> > > See, in my application,
> > > I have no way of knowing in advance if a logged-in user is authorized
> > > to access
> > > a particular resource. I'm trying to accomplish that programatically.
>
> > Well if when authenticating a user (LiftRules.authentication) you
> > can't determine the Role, then this mechanism probably won't help you
> > and you need to build your own.
>
> > > And, don't forget, roles
> > > can be changed at any time in the application.
>
> > I assume that a "super-admin" user would be able to change roles for
> > other users right? ... If so you just need to update data in your DB
> > for say user X. So when User X authenticates you'll get the new role
> > assigned. But maybe this is not how your app is designed to work.
>
> > > In other words, I
> > > can't just assume it in my
> > > authentication function and make the assignment there.
>
> > > Does that make sense? This is not to say that I can't work
> > > tangentially to Http basic authentication
> > > in Lift and create my own, just that I'm trying to incorporate the
> > > work already done so I don't have to.
>
> > Lift's HTTP authentication and authorization is built on very simple
> > principles such as:
>
> > 1. In the authentication function you typically know the role for that
> > user.
> > 2. Resources (URI's essentially) are protected by hierarchically
> > structured roles that are matched with the role determined by the
> > authentication function.
>
> > > Glenn
>
> > > On Sep 7, 11:24 pm, "marius d." wrote:
>
> > > > On Sep 8, 1:18 am, glenn wrote:
>
> > > > > Marius,
>
> > > > > Please bear with me. I'm a little slow in following the logic here.
>
> > > > Don't worry glen.
>
> > > > > I understand I can protect the resource as you suggest from all
> > > > > but users with admin roles, using the LocParam,
>
> > > > > HttpAuthProtected(() => Full(AuthRole("admin") .
>
> > > > > Now, when I click on the link, if no user is logged in, the system
> > > > > asks for a username and password to connect, but that's a user
> > > > > on the host. not an application user.
>
> > > > Not necessarily. It is any type of user. In your authentication
> > > > function you can go in DB and validate the receiving credentials as
> > > > application user.
>
> > > > > Somewhere, I need to assign the
> > > > > currently logged in user the AuthRole("admin") needed to access
> > > > > the resource.
>
> > > > Correct. And you dothis by setting userRoles RequestVar.
>
> > > > > Seems to me I need code like this to run someplace:
>
> > > > > def authorize(roleName:String): Box[Role] = {
> > > > > object userRoles extends RequestVar[Role](null)
>
> > > > > val credentials : (String,String) = User.currentUser match {
> > > > > case Full(u) => (u.email.is, u.password.is)
> > > > > case Empty => (null, null)
> > > > > }
>
> > > > > User.isa_?(roleName) match {
> > > > > case true => {
> > > > > LiftRules.authentication = HttpBasicAuthentication("lift")
> > > > > {
> > > > > case (credentials._1, credentials._2, req) =>
> > > > > println("John is authenticated!")
> > > > >
> > > > > userRoles(_root_.net.liftweb.http.auth.AuthRole
> > > > > (roleName))
> > > > > true
> > > > > }
> > > > > Full(new _root_.net.liftweb.http.auth.Role{
> > > > > def name = roleName})
> > > > > }
> > > > > case false => Empty
> > > > > }
> > > > > }
>
> > > > > Can't be in Boot,
>
> > > > No you do not. Lift takes care of the roles matching for you. You
> > > > don't need to manually test if a user is-an admin or some other role
> > > > in order to access that resource. Please keep in mind that is just for
> > > > accessing resources (URI-s) if you need to do more complex logic in
> > > > your code and see if the user is an admin or having some other Role
[Lift] Re: Using Roles and LIftRules.authentication
Marius,
I guess there is little more to be said on this issue. Keep in mind
that
in many real-world applications, dynamically assigned user roles are a
requirement. And it's possible for users to have multiple roles, each
in a different role hierarchy, in the same application.
Inevitably, I will have to implement my own, perhaps using
JaaS or one of its variants. If you have any thoughts on that issue,
I'd like to hear them.
Thanks,
Glenn
On Sep 8, 8:40 am, "marius d." wrote:
> On Sep 8, 6:12 pm, glenn wrote:
>
> > Marius,
>
> > With your help, I think I'm getting closer to understanding what is
> > needed
> > here.
>
> > One thing though, is that I believe I do need to manually check if the
> > user has the
> > appropriate role (in the DB) before I can set userRoles RequestVar.
> > See, in my application,
> > I have no way of knowing in advance if a logged-in user is authorized
> > to access
> > a particular resource. I'm trying to accomplish that programatically.
>
> Well if when authenticating a user (LiftRules.authentication) you
> can't determine the Role, then this mechanism probably won't help you
> and you need to build your own.
>
> > And, don't forget, roles
> > can be changed at any time in the application.
>
> I assume that a "super-admin" user would be able to change roles for
> other users right? ... If so you just need to update data in your DB
> for say user X. So when User X authenticates you'll get the new role
> assigned. But maybe this is not how your app is designed to work.
>
> > In other words, I
> > can't just assume it in my
> > authentication function and make the assignment there.
>
> > Does that make sense? This is not to say that I can't work
> > tangentially to Http basic authentication
> > in Lift and create my own, just that I'm trying to incorporate the
> > work already done so I don't have to.
>
> Lift's HTTP authentication and authorization is built on very simple
> principles such as:
>
> 1. In the authentication function you typically know the role for that
> user.
> 2. Resources (URI's essentially) are protected by hierarchically
> structured roles that are matched with the role determined by the
> authentication function.
>
>
>
> > Glenn
>
> > On Sep 7, 11:24 pm, "marius d." wrote:
>
> > > On Sep 8, 1:18 am, glenn wrote:
>
> > > > Marius,
>
> > > > Please bear with me. I'm a little slow in following the logic here.
>
> > > Don't worry glen.
>
> > > > I understand I can protect the resource as you suggest from all
> > > > but users with admin roles, using the LocParam,
>
> > > > HttpAuthProtected(() => Full(AuthRole("admin") .
>
> > > > Now, when I click on the link, if no user is logged in, the system
> > > > asks for a username and password to connect, but that's a user
> > > > on the host. not an application user.
>
> > > Not necessarily. It is any type of user. In your authentication
> > > function you can go in DB and validate the receiving credentials as
> > > application user.
>
> > > > Somewhere, I need to assign the
> > > > currently logged in user the AuthRole("admin") needed to access
> > > > the resource.
>
> > > Correct. And you dothis by setting userRoles RequestVar.
>
> > > > Seems to me I need code like this to run someplace:
>
> > > > def authorize(roleName:String): Box[Role] = {
> > > > object userRoles extends RequestVar[Role](null)
>
> > > > val credentials : (String,String) = User.currentUser match {
> > > > case Full(u) => (u.email.is, u.password.is)
> > > > case Empty => (null, null)
> > > > }
>
> > > > User.isa_?(roleName) match {
> > > > case true => {
> > > > LiftRules.authentication = HttpBasicAuthentication("lift")
> > > > {
> > > > case (credentials._1, credentials._2, req) =>
> > > > println("John is authenticated!")
> > > > userRoles(_root_.net.liftweb.http.auth.AuthRole
> > > > (roleName))
> > > > true
> > > > }
> > > > Full(new _root_.net.liftweb.http.auth.Role{
> > > > def name = roleName})
> > > > }
> > > > case false => Empty
> > > > }
> > > > }
>
> > > > Can't be in Boot,
>
> > > No you do not. Lift takes care of the roles matching for you. You
> > > don't need to manually test if a user is-an admin or some other role
> > > in order to access that resource. Please keep in mind that is just for
> > > accessing resources (URI-s) if you need to do more complex logic in
> > > your code and see if the user is an admin or having some other Role
> > > that you'd probably need to save the Role into a SessionVar or into
> > > your User object.
>
> > > All I want here is to explain how HTTP based authentication and roles
> > > based authorization works. I am definitely not claiming that this is
> > > enough for all applications as currently we don't have HTTP based
> > > authentication with forms for example .
[Lift] Re: Using Roles and LIftRules.authentication
On Sep 8, 6:12 pm, glenn wrote:
> Marius,
>
> With your help, I think I'm getting closer to understanding what is
> needed
> here.
>
> One thing though, is that I believe I do need to manually check if the
> user has the
> appropriate role (in the DB) before I can set userRoles RequestVar.
> See, in my application,
> I have no way of knowing in advance if a logged-in user is authorized
> to access
> a particular resource. I'm trying to accomplish that programatically.
Well if when authenticating a user (LiftRules.authentication) you
can't determine the Role, then this mechanism probably won't help you
and you need to build your own.
> And, don't forget, roles
> can be changed at any time in the application.
I assume that a "super-admin" user would be able to change roles for
other users right? ... If so you just need to update data in your DB
for say user X. So when User X authenticates you'll get the new role
assigned. But maybe this is not how your app is designed to work.
> In other words, I
> can't just assume it in my
> authentication function and make the assignment there.
>
> Does that make sense? This is not to say that I can't work
> tangentially to Http basic authentication
> in Lift and create my own, just that I'm trying to incorporate the
> work already done so I don't have to.
Lift's HTTP authentication and authorization is built on very simple
principles such as:
1. In the authentication function you typically know the role for that
user.
2. Resources (URI's essentially) are protected by hierarchically
structured roles that are matched with the role determined by the
authentication function.
>
> Glenn
>
> On Sep 7, 11:24 pm, "marius d." wrote:
>
> > On Sep 8, 1:18 am, glenn wrote:
>
> > > Marius,
>
> > > Please bear with me. I'm a little slow in following the logic here.
>
> > Don't worry glen.
>
> > > I understand I can protect the resource as you suggest from all
> > > but users with admin roles, using the LocParam,
>
> > > HttpAuthProtected(() => Full(AuthRole("admin") .
>
> > > Now, when I click on the link, if no user is logged in, the system
> > > asks for a username and password to connect, but that's a user
> > > on the host. not an application user.
>
> > Not necessarily. It is any type of user. In your authentication
> > function you can go in DB and validate the receiving credentials as
> > application user.
>
> > > Somewhere, I need to assign the
> > > currently logged in user the AuthRole("admin") needed to access
> > > the resource.
>
> > Correct. And you dothis by setting userRoles RequestVar.
>
> > > Seems to me I need code like this to run someplace:
>
> > > def authorize(roleName:String): Box[Role] = {
> > > object userRoles extends RequestVar[Role](null)
>
> > > val credentials : (String,String) = User.currentUser match {
> > > case Full(u) => (u.email.is, u.password.is)
> > > case Empty => (null, null)
> > > }
>
> > > User.isa_?(roleName) match {
> > > case true => {
> > > LiftRules.authentication = HttpBasicAuthentication("lift")
> > > {
> > > case (credentials._1, credentials._2, req) =>
> > > println("John is authenticated!")
> > > userRoles(_root_.net.liftweb.http.auth.AuthRole
> > > (roleName))
> > > true
> > > }
> > > Full(new _root_.net.liftweb.http.auth.Role{
> > > def name = roleName})
> > > }
> > > case false => Empty
> > > }
> > > }
>
> > > Can't be in Boot,
>
> > No you do not. Lift takes care of the roles matching for you. You
> > don't need to manually test if a user is-an admin or some other role
> > in order to access that resource. Please keep in mind that is just for
> > accessing resources (URI-s) if you need to do more complex logic in
> > your code and see if the user is an admin or having some other Role
> > that you'd probably need to save the Role into a SessionVar or into
> > your User object.
>
> > All I want here is to explain how HTTP based authentication and roles
> > based authorization works. I am definitely not claiming that this is
> > enough for all applications as currently we don't have HTTP based
> > authentication with forms for example ... but I think we should add
> > that as well.
>
> > > Glenn
>
> > > On Sep 7, 1:36 pm, "marius d." wrote:
>
> > > > On Sep 7, 10:53 pm, glenn wrote:
>
> > > > > Marius,
>
> > > > > In practical terms, if I am already using an If LocParam, as in the
> > > > > following:
>
> > > > > If(() => User.isa_?("admin"), S.?("not_authorized"))
>
> > > > > what does adding
>
> > > > > HttpAuthProtected(() => User.authorize("admin")) to the Loc do?
>
> > > > It sais that this Loc is protected by the returned Role. Thus to
> > > > access this after passing the authentication the Role specified in the
> > > > authentication function (by setting userRoles) must be the same as o
[Lift] Re: Using Roles and LIftRules.authentication
Marius,
With your help, I think I'm getting closer to understanding what is
needed
here.
One thing though, is that I believe I do need to manually check if the
user has the
appropriate role (in the DB) before I can set userRoles RequestVar.
See, in my application,
I have no way of knowing in advance if a logged-in user is authorized
to access
a particular resource. I'm trying to accomplish that programatically.
And, don't forget, roles
can be changed at any time in the application. In other words, I
can't just assume it in my
authentication function and make the assignment there.
Does that make sense? This is not to say that I can't work
tangentially to Http basic authentication
in Lift and create my own, just that I'm trying to incorporate the
work already done so I don't have to.
Glenn
On Sep 7, 11:24 pm, "marius d." wrote:
> On Sep 8, 1:18 am, glenn wrote:
>
> > Marius,
>
> > Please bear with me. I'm a little slow in following the logic here.
>
> Don't worry glen.
>
>
>
> > I understand I can protect the resource as you suggest from all
> > but users with admin roles, using the LocParam,
>
> > HttpAuthProtected(() => Full(AuthRole("admin") .
>
> > Now, when I click on the link, if no user is logged in, the system
> > asks for a username and password to connect, but that's a user
> > on the host. not an application user.
>
> Not necessarily. It is any type of user. In your authentication
> function you can go in DB and validate the receiving credentials as
> application user.
>
> > Somewhere, I need to assign the
> > currently logged in user the AuthRole("admin") needed to access
> > the resource.
>
> Correct. And you dothis by setting userRoles RequestVar.
>
>
>
>
>
> > Seems to me I need code like this to run someplace:
>
> > def authorize(roleName:String): Box[Role] = {
> > object userRoles extends RequestVar[Role](null)
>
> > val credentials : (String,String) = User.currentUser match {
> > case Full(u) => (u.email.is, u.password.is)
> > case Empty => (null, null)
> > }
>
> > User.isa_?(roleName) match {
> > case true => {
> > LiftRules.authentication = HttpBasicAuthentication("lift")
> > {
> > case (credentials._1, credentials._2, req) =>
> > println("John is authenticated!")
> > userRoles(_root_.net.liftweb.http.auth.AuthRole
> > (roleName))
> > true
> > }
> > Full(new _root_.net.liftweb.http.auth.Role{
> > def name = roleName})
> > }
> > case false => Empty
> > }
> > }
>
> > Can't be in Boot,
>
> No you do not. Lift takes care of the roles matching for you. You
> don't need to manually test if a user is-an admin or some other role
> in order to access that resource. Please keep in mind that is just for
> accessing resources (URI-s) if you need to do more complex logic in
> your code and see if the user is an admin or having some other Role
> that you'd probably need to save the Role into a SessionVar or into
> your User object.
>
> All I want here is to explain how HTTP based authentication and roles
> based authorization works. I am definitely not claiming that this is
> enough for all applications as currently we don't have HTTP based
> authentication with forms for example ... but I think we should add
> that as well.
>
>
>
> > Glenn
>
> > On Sep 7, 1:36 pm, "marius d." wrote:
>
> > > On Sep 7, 10:53 pm, glenn wrote:
>
> > > > Marius,
>
> > > > In practical terms, if I am already using an If LocParam, as in the
> > > > following:
>
> > > > If(() => User.isa_?("admin"), S.?("not_authorized"))
>
> > > > what does adding
>
> > > > HttpAuthProtected(() => User.authorize("admin")) to the Loc do?
>
> > > It sais that this Loc is protected by the returned Role. Thus to
> > > access this after passing the authentication the Role specified in the
> > > authentication function (by setting userRoles) must be the same as or
> > > a child of the Role the is protecting the Loc.
>
> > > > Here, I've had to define User.authorize to make things work, as:
>
> > > > def authorize(roleName:String): Box[Role] = {
> > > > val credentials : (String,String) = User.currentUser match {
> > > > case Full(u) => (u.email.is, u.password.is)
> > > > case Empty => (null, null)
> > > > }
>
> > > > User.isa_?(roleName) match {
> > > > case true => {
> > > > LiftRules.httpAuthProtectedResource.append {
> > > > case (ParsePath("listContents" :: _, _, _, _)) => Full
> > > > (AuthRole("admin"))
> > > > }
>
> > > Why do you need to use httpAuthProtectedResource if you' using
> > > HttpAuthProtected LocParam ?
>
> > > > LiftRules.authentication = HttpBasicAuthentication("lift")
> > > > {
> > > > case (credentials._1, credentials._2, req) =>
> > > > AuthRole(roleNa
[Lift] Re: Using Roles and LIftRules.authentication
On Sep 8, 1:18 am, glenn wrote:
> Marius,
>
> Please bear with me. I'm a little slow in following the logic here.
Don't worry glen.
>
> I understand I can protect the resource as you suggest from all
> but users with admin roles, using the LocParam,
>
> HttpAuthProtected(() => Full(AuthRole("admin") .
>
> Now, when I click on the link, if no user is logged in, the system
> asks for a username and password to connect, but that's a user
> on the host. not an application user.
Not necessarily. It is any type of user. In your authentication
function you can go in DB and validate the receiving credentials as
application user.
> Somewhere, I need to assign the
> currently logged in user the AuthRole("admin") needed to access
> the resource.
Correct. And you dothis by setting userRoles RequestVar.
>
> Seems to me I need code like this to run someplace:
>
> def authorize(roleName:String): Box[Role] = {
> object userRoles extends RequestVar[Role](null)
>
> val credentials : (String,String) = User.currentUser match {
> case Full(u) => (u.email.is, u.password.is)
> case Empty => (null, null)
> }
>
> User.isa_?(roleName) match {
> case true => {
> LiftRules.authentication = HttpBasicAuthentication("lift")
> {
> case (credentials._1, credentials._2, req) =>
> println("John is authenticated!")
> userRoles(_root_.net.liftweb.http.auth.AuthRole
> (roleName))
> true
> }
> Full(new _root_.net.liftweb.http.auth.Role{
> def name = roleName})
> }
> case false => Empty
> }
> }
>
> Can't be in Boot,
No you do not. Lift takes care of the roles matching for you. You
don't need to manually test if a user is-an admin or some other role
in order to access that resource. Please keep in mind that is just for
accessing resources (URI-s) if you need to do more complex logic in
your code and see if the user is an admin or having some other Role
that you'd probably need to save the Role into a SessionVar or into
your User object.
All I want here is to explain how HTTP based authentication and roles
based authorization works. I am definitely not claiming that this is
enough for all applications as currently we don't have HTTP based
authentication with forms for example ... but I think we should add
that as well.
>
> Glenn
>
> On Sep 7, 1:36 pm, "marius d." wrote:
>
> > On Sep 7, 10:53 pm, glenn wrote:
>
> > > Marius,
>
> > > In practical terms, if I am already using an If LocParam, as in the
> > > following:
>
> > > If(() => User.isa_?("admin"), S.?("not_authorized"))
>
> > > what does adding
>
> > > HttpAuthProtected(() => User.authorize("admin")) to the Loc do?
>
> > It sais that this Loc is protected by the returned Role. Thus to
> > access this after passing the authentication the Role specified in the
> > authentication function (by setting userRoles) must be the same as or
> > a child of the Role the is protecting the Loc.
>
> > > Here, I've had to define User.authorize to make things work, as:
>
> > > def authorize(roleName:String): Box[Role] = {
> > > val credentials : (String,String) = User.currentUser match {
> > > case Full(u) => (u.email.is, u.password.is)
> > > case Empty => (null, null)
> > > }
>
> > > User.isa_?(roleName) match {
> > > case true => {
> > > LiftRules.httpAuthProtectedResource.append {
> > > case (ParsePath("listContents" :: _, _, _, _)) => Full
> > > (AuthRole("admin"))
> > > }
>
> > Why do you need to use httpAuthProtectedResource if you' using
> > HttpAuthProtected LocParam ?
>
> > > LiftRules.authentication = HttpBasicAuthentication("lift")
> > > {
> > > case (credentials._1, credentials._2, req) =>
> > > AuthRole(roleName)
> > > true
> > > }
> > > Full(new _root_.net.liftweb.http.auth.Role{
> > > def name = roleName})
> > > }
> > > case false => Empty
> > > }
>
> > > Rather verbose, don't you think.
>
> > Your code is verbose but I don't see the justification for this
> > verbosity:
>
> > LiftRules.authentication = HttpBasicAuthentication("lift") {
> > case (username, password, req) => {
> > // Do you authentication in DB or whatever and you
> > determined that this is an admin user
> > userRoles(AuthRole("admin")) // userRoles needs to be
> > set. It is a RquestVar.
> > true
> > }
>
> > In Boot you have:
>
> > Menu(Loc("listContents", List("listContents"), "listContents",
> > HttpAuthProtected(() => Full(AuthRole("admin")
>
> > When you use HttpAuthProtected LocParam Lift appends a function to
> > LiftRules.httpAuthProtectedResource so you don't need to do it
> > manually.
>
[Lift] Re: Using Roles and LIftRules.authentication
Marius,
Please bear with me. I'm a little slow in following the logic here.
I understand I can protect the resource as you suggest from all
but users with admin roles, using the LocParam,
HttpAuthProtected(() => Full(AuthRole("admin") .
Now, when I click on the link, if no user is logged in, the system
asks for a username and password to connect, but that's a user
on the host. not an application user. Somewhere, I need to assign the
currently logged in user the AuthRole("admin") needed to access
the resource.
Seems to me I need code like this to run someplace:
def authorize(roleName:String): Box[Role] = {
object userRoles extends RequestVar[Role](null)
val credentials : (String,String) = User.currentUser match {
case Full(u) => (u.email.is, u.password.is)
case Empty => (null, null)
}
User.isa_?(roleName) match {
case true => {
LiftRules.authentication = HttpBasicAuthentication("lift")
{
case (credentials._1, credentials._2, req) =>
println("John is authenticated!")
userRoles(_root_.net.liftweb.http.auth.AuthRole
(roleName))
true
}
Full(new _root_.net.liftweb.http.auth.Role{
def name = roleName})
}
case false => Empty
}
}
Can't be in Boot,
Glenn
On Sep 7, 1:36 pm, "marius d." wrote:
> On Sep 7, 10:53 pm, glenn wrote:
>
> > Marius,
>
> > In practical terms, if I am already using an If LocParam, as in the
> > following:
>
> > If(() => User.isa_?("admin"), S.?("not_authorized"))
>
> > what does adding
>
> > HttpAuthProtected(() => User.authorize("admin")) to the Loc do?
>
> It sais that this Loc is protected by the returned Role. Thus to
> access this after passing the authentication the Role specified in the
> authentication function (by setting userRoles) must be the same as or
> a child of the Role the is protecting the Loc.
>
>
>
> > Here, I've had to define User.authorize to make things work, as:
>
> > def authorize(roleName:String): Box[Role] = {
> > val credentials : (String,String) = User.currentUser match {
> > case Full(u) => (u.email.is, u.password.is)
> > case Empty => (null, null)
> > }
>
> > User.isa_?(roleName) match {
> > case true => {
> > LiftRules.httpAuthProtectedResource.append {
> > case (ParsePath("listContents" :: _, _, _, _)) => Full
> > (AuthRole("admin"))
> > }
>
> Why do you need to use httpAuthProtectedResource if you' using
> HttpAuthProtected LocParam ?
>
> > LiftRules.authentication = HttpBasicAuthentication("lift")
> > {
> > case (credentials._1, credentials._2, req) =>
> > AuthRole(roleName)
> > true
> > }
> > Full(new _root_.net.liftweb.http.auth.Role{
> > def name = roleName})
> > }
> > case false => Empty
> > }
>
> > Rather verbose, don't you think.
>
> Your code is verbose but I don't see the justification for this
> verbosity:
>
> LiftRules.authentication = HttpBasicAuthentication("lift") {
> case (username, password, req) => {
> // Do you authentication in DB or whatever and you
> determined that this is an admin user
> userRoles(AuthRole("admin")) // userRoles needs to be
> set. It is a RquestVar.
> true
> }
>
> In Boot you have:
>
> Menu(Loc("listContents", List("listContents"), "listContents",
> HttpAuthProtected(() => Full(AuthRole("admin")
>
> When you use HttpAuthProtected LocParam Lift appends a function to
> LiftRules.httpAuthProtectedResource so you don't need to do it
> manually.
>
> This authorixation scheme is only about protecting resource by roles
> and you do this almost declaratively and for authentication I thing
> the things are pretty straight forward. One a user is authenticated
> (using HTTP authentication) you need to specify the Role for this user
> and you do this using userRoles RequestVar.Thus /listContents can only
> be accessed if:
>
> 1. user passed authentications
> 2. user's Role is an "admin" or a child of the Role specified in
> HttpAuthProtected
>
>
>
> > elipsisless Glenn
>
> > On Sep 6, 8:27 am, Timothy Perrett wrote:
>
> > > Right, i know it has a sitemap aspect... just based on what chas has
> > > asked about RBAC before, I can only presume he's still looking for
> > > more granularity than sitemap offers :-)
>
> > > Perhaps it might work for Glenn though...
>
> > > Cheers, Tim
>
> > > On Sep 6, 3:44 pm, "marius d." wrote:
>
> > > > Glen,
>
> > > > Tim is correct however HTTP auth support + it's Role model can be used
> > > > for SiteMenu as well. Please see:
>
> > > > case class HttpAuthProtected(role: () => Box[Role]) extends LocParam
>
> > > > You easily can specify that a Loc is a protected resou
[Lift] Re: Using Roles and LIftRules.authentication
On Sep 7, 10:53 pm, glenn wrote:
> Marius,
>
> In practical terms, if I am already using an If LocParam, as in the
> following:
>
> If(() => User.isa_?("admin"), S.?("not_authorized"))
>
> what does adding
>
> HttpAuthProtected(() => User.authorize("admin")) to the Loc do?
It sais that this Loc is protected by the returned Role. Thus to
access this after passing the authentication the Role specified in the
authentication function (by setting userRoles) must be the same as or
a child of the Role the is protecting the Loc.
>
> Here, I've had to define User.authorize to make things work, as:
>
> def authorize(roleName:String): Box[Role] = {
> val credentials : (String,String) = User.currentUser match {
> case Full(u) => (u.email.is, u.password.is)
> case Empty => (null, null)
> }
>
> User.isa_?(roleName) match {
> case true => {
> LiftRules.httpAuthProtectedResource.append {
> case (ParsePath("listContents" :: _, _, _, _)) => Full
> (AuthRole("admin"))
> }
Why do you need to use httpAuthProtectedResource if you' using
HttpAuthProtected LocParam ?
> LiftRules.authentication = HttpBasicAuthentication("lift")
> {
> case (credentials._1, credentials._2, req) =>
> AuthRole(roleName)
> true
> }
> Full(new _root_.net.liftweb.http.auth.Role{
> def name = roleName})
> }
> case false => Empty
> }
>
> Rather verbose, don't you think.
Your code is verbose but I don't see the justification for this
verbosity:
LiftRules.authentication = HttpBasicAuthentication("lift") {
case (username, password, req) => {
// Do you authentication in DB or whatever and you
determined that this is an admin user
userRoles(AuthRole("admin")) // userRoles needs to be
set. It is a RquestVar.
true
}
In Boot you have:
Menu(Loc("listContents", List("listContents"), "listContents",
HttpAuthProtected(() => Full(AuthRole("admin")
When you use HttpAuthProtected LocParam Lift appends a function to
LiftRules.httpAuthProtectedResource so you don't need to do it
manually.
This authorixation scheme is only about protecting resource by roles
and you do this almost declaratively and for authentication I thing
the things are pretty straight forward. One a user is authenticated
(using HTTP authentication) you need to specify the Role for this user
and you do this using userRoles RequestVar.Thus /listContents can only
be accessed if:
1. user passed authentications
2. user's Role is an "admin" or a child of the Role specified in
HttpAuthProtected
>
> elipsisless Glenn
>
> On Sep 6, 8:27 am, Timothy Perrett wrote:
>
> > Right, i know it has a sitemap aspect... just based on what chas has
> > asked about RBAC before, I can only presume he's still looking for
> > more granularity than sitemap offers :-)
>
> > Perhaps it might work for Glenn though...
>
> > Cheers, Tim
>
> > On Sep 6, 3:44 pm, "marius d." wrote:
>
> > > Glen,
>
> > > Tim is correct however HTTP auth support + it's Role model can be used
> > > for SiteMenu as well. Please see:
>
> > > case class HttpAuthProtected(role: () => Box[Role]) extends LocParam
>
> > > You easily can specify that a Loc is a protected resource you just
> > > need to return the Role that guards this resource. This Loc will be
> > > served only if HTTP authentication succeeds and the Role match.
>
> > > So this is an RBAC.
>
> > > Br's,
> > > Marius
>
> > > On Sep 5, 7:57 pm, Timothy Perrett wrote:
>
> > > > Glenn, its simply not designed to do what your asking - however, the
> > > > most "lift way" of doing access control is with SiteMap, so
> > > > potentially look into that as a solution. You don't detail your needs,
> > > > but we've had this conversation several times on-list so just look
> > > > through the archives and that might spawn some other ideas for you.
>
> > > > Tim
>
> > > > PS: Is there any good reason you always put an ellipsis after your
> > > > name? For some reason it bothers me quite a bit!
>
> > > > On Sep 5, 5:32 pm, glenn wrote:
>
> > > > > Marius,
>
> > > > > I appreciate your reply, but the question I asked regards useage of
> > > > > the Role trait in what Charles
> > > > > refers to as a Role-Based Access Control (RBAC) system. I could not
> > > > > find this addressed in the
> > > > > Lift Book and, no, there is no illuminating code in the lift-
> > > > > authentication example. It's established
> > > > > the trait is not a good mixin for a mapper class in maintaining
> > > > > persistent role/access
> > > > > data. I was asking, on a lark, if anyone had ideas on a pattern that
> > > > > might help. I guess
> > > > > I've gotten an answer - No.
>
> > > > > I certainly don't expect Lift, out-of-the-box, to provide a complete
> > > > > authorization package
> > > > > and I would have be
[Lift] Re: Using Roles and LIftRules.authentication
Tim,
You are right. Protecting resources and menu items is well documented
in Lift. But providing read/write permissions, and even restricting
access to
specific data entities based on a subject's role, if that's what you
mean by
more granularity, is often a required use case in an application.
Dividing up read-only views and editable templates into different
resources helps. And limiting data access is certainly doable. It
would just
be nice to centralize some of these features, and that's what I'm
trying achieve in my
code.
Glenn . - oops, I almost lost myself there.
On Sep 7, 12:53 pm, glenn wrote:
> Marius,
>
> In practical terms, if I am already using an If LocParam, as in the
> following:
>
> If(() => User.isa_?("admin"), S.?("not_authorized"))
>
> what does adding
>
> HttpAuthProtected(() => User.authorize("admin")) to the Loc do?
>
> Here, I've had to define User.authorize to make things work, as:
>
> def authorize(roleName:String): Box[Role] = {
> val credentials : (String,String) = User.currentUser match {
> case Full(u) => (u.email.is, u.password.is)
> case Empty => (null, null)
> }
>
> User.isa_?(roleName) match {
> case true => {
> LiftRules.httpAuthProtectedResource.append {
> case (ParsePath("listContents" :: _, _, _, _)) => Full
> (AuthRole("admin"))
> }
> LiftRules.authentication = HttpBasicAuthentication("lift")
> {
> case (credentials._1, credentials._2, req) =>
> AuthRole(roleName)
> true
> }
> Full(new _root_.net.liftweb.http.auth.Role{
> def name = roleName})
> }
> case false => Empty
> }
>
> Rather verbose, don't you think.
>
> elipsisless Glenn
>
> On Sep 6, 8:27 am, Timothy Perrett wrote:
>
> > Right, i know it has a sitemap aspect... just based on what chas has
> > asked about RBAC before, I can only presume he's still looking for
> > more granularity than sitemap offers :-)
>
> > Perhaps it might work for Glenn though...
>
> > Cheers, Tim
>
> > On Sep 6, 3:44 pm, "marius d." wrote:
>
> > > Glen,
>
> > > Tim is correct however HTTP auth support + it's Role model can be used
> > > for SiteMenu as well. Please see:
>
> > > case class HttpAuthProtected(role: () => Box[Role]) extends LocParam
>
> > > You easily can specify that a Loc is a protected resource you just
> > > need to return the Role that guards this resource. This Loc will be
> > > served only if HTTP authentication succeeds and the Role match.
>
> > > So this is an RBAC.
>
> > > Br's,
> > > Marius
>
> > > On Sep 5, 7:57 pm, Timothy Perrett wrote:
>
> > > > Glenn, its simply not designed to do what your asking - however, the
> > > > most "lift way" of doing access control is with SiteMap, so
> > > > potentially look into that as a solution. You don't detail your needs,
> > > > but we've had this conversation several times on-list so just look
> > > > through the archives and that might spawn some other ideas for you.
>
> > > > Tim
>
> > > > PS: Is there any good reason you always put an ellipsis after your
> > > > name? For some reason it bothers me quite a bit!
>
> > > > On Sep 5, 5:32 pm, glenn wrote:
>
> > > > > Marius,
>
> > > > > I appreciate your reply, but the question I asked regards useage of
> > > > > the Role trait in what Charles
> > > > > refers to as a Role-Based Access Control (RBAC) system. I could not
> > > > > find this addressed in the
> > > > > Lift Book and, no, there is no illuminating code in the lift-
> > > > > authentication example. It's established
> > > > > the trait is not a good mixin for a mapper class in maintaining
> > > > > persistent role/access
> > > > > data. I was asking, on a lark, if anyone had ideas on a pattern that
> > > > > might help. I guess
> > > > > I've gotten an answer - No.
>
> > > > > I certainly don't expect Lift, out-of-the-box, to provide a complete
> > > > > authorization package
> > > > > and I would have been surprised if it had.
>
> > > > > Glenn...
>
> > > > > On Sep 5, 12:38 am, "marius d." wrote:
>
> > > > > > I'll let Tim provide you a concrete code example but AFAIK there is
> > > > > > a
> > > > > > lift-authetication example in examples?
>
> > > > > > A few points:
>
> > > > > > 1. We support both BASIC and DIGEST HTTP authentication
> > > > > > 2. First, to apply authentication you need to specify which resource
> > > > > > (by URI) is a protected resource. Here we say that resource X is
> > > > > > protected by Role A (Roles are hierarchicaly structured)
> > > > > > 3. Secondly you set up the authentication function in Boot (for
> > > > > > Basic
> > > > > > or Digest) you check the credentials. If authentication succeeds
> > > > > > that
> > > > > > request is being processed.
>
> > > > > > Here is an example from lift-authentication:
>
> > > > > > LiftRules.httpAuthProtectedResource.prepend {
> > > > > >
[Lift] Re: Using Roles and LIftRules.authentication
Marius,
In practical terms, if I am already using an If LocParam, as in the
following:
If(() => User.isa_?("admin"), S.?("not_authorized"))
what does adding
HttpAuthProtected(() => User.authorize("admin")) to the Loc do?
Here, I've had to define User.authorize to make things work, as:
def authorize(roleName:String): Box[Role] = {
val credentials : (String,String) = User.currentUser match {
case Full(u) => (u.email.is, u.password.is)
case Empty => (null, null)
}
User.isa_?(roleName) match {
case true => {
LiftRules.httpAuthProtectedResource.append {
case (ParsePath("listContents" :: _, _, _, _)) => Full
(AuthRole("admin"))
}
LiftRules.authentication = HttpBasicAuthentication("lift")
{
case (credentials._1, credentials._2, req) =>
AuthRole(roleName)
true
}
Full(new _root_.net.liftweb.http.auth.Role{
def name = roleName})
}
case false => Empty
}
Rather verbose, don't you think.
elipsisless Glenn
On Sep 6, 8:27 am, Timothy Perrett wrote:
> Right, i know it has a sitemap aspect... just based on what chas has
> asked about RBAC before, I can only presume he's still looking for
> more granularity than sitemap offers :-)
>
> Perhaps it might work for Glenn though...
>
> Cheers, Tim
>
> On Sep 6, 3:44 pm, "marius d." wrote:
>
> > Glen,
>
> > Tim is correct however HTTP auth support + it's Role model can be used
> > for SiteMenu as well. Please see:
>
> > case class HttpAuthProtected(role: () => Box[Role]) extends LocParam
>
> > You easily can specify that a Loc is a protected resource you just
> > need to return the Role that guards this resource. This Loc will be
> > served only if HTTP authentication succeeds and the Role match.
>
> > So this is an RBAC.
>
> > Br's,
> > Marius
>
> > On Sep 5, 7:57 pm, Timothy Perrett wrote:
>
> > > Glenn, its simply not designed to do what your asking - however, the
> > > most "lift way" of doing access control is with SiteMap, so
> > > potentially look into that as a solution. You don't detail your needs,
> > > but we've had this conversation several times on-list so just look
> > > through the archives and that might spawn some other ideas for you.
>
> > > Tim
>
> > > PS: Is there any good reason you always put an ellipsis after your
> > > name? For some reason it bothers me quite a bit!
>
> > > On Sep 5, 5:32 pm, glenn wrote:
>
> > > > Marius,
>
> > > > I appreciate your reply, but the question I asked regards useage of
> > > > the Role trait in what Charles
> > > > refers to as a Role-Based Access Control (RBAC) system. I could not
> > > > find this addressed in the
> > > > Lift Book and, no, there is no illuminating code in the lift-
> > > > authentication example. It's established
> > > > the trait is not a good mixin for a mapper class in maintaining
> > > > persistent role/access
> > > > data. I was asking, on a lark, if anyone had ideas on a pattern that
> > > > might help. I guess
> > > > I've gotten an answer - No.
>
> > > > I certainly don't expect Lift, out-of-the-box, to provide a complete
> > > > authorization package
> > > > and I would have been surprised if it had.
>
> > > > Glenn...
>
> > > > On Sep 5, 12:38 am, "marius d." wrote:
>
> > > > > I'll let Tim provide you a concrete code example but AFAIK there is a
> > > > > lift-authetication example in examples?
>
> > > > > A few points:
>
> > > > > 1. We support both BASIC and DIGEST HTTP authentication
> > > > > 2. First, to apply authentication you need to specify which resource
> > > > > (by URI) is a protected resource. Here we say that resource X is
> > > > > protected by Role A (Roles are hierarchicaly structured)
> > > > > 3. Secondly you set up the authentication function in Boot (for Basic
> > > > > or Digest) you check the credentials. If authentication succeeds that
> > > > > request is being processed.
>
> > > > > Here is an example from lift-authentication:
>
> > > > > LiftRules.httpAuthProtectedResource.prepend {
> > > > > case (ParsePath("secure-basic" :: Nil, _, _, _)) =>
> > > > > Full(AuthRole("admin"))
> > > > > }
> > > > > // This resource is protected by an AuthRole named admin.
>
> > > > > LiftRules.authentication = HttpBasicAuthentication("lift") {
> > > > > case ("someuser", "1234", req) => {
> > > > > Log.info("You are now authenticated !")
> > > > > userRoles(AuthRole("admin"))
> > > > > true
> > > > > }
> > > > > }
>
> > > > > When we try to access /secure-basic resource HTTP basic auth. is
> > > > > applied. If
> > > > > credentials are correct we set the AuthRole as admin on the
> > > > > Requestvar
> > > > > userRoles. If we would have set another role such as userRoles
> > > > > (AuthRole
> > > > > ("guest")) the resource would still not be serv
[Lift] Re: Using Roles and LIftRules.authentication
Right, i know it has a sitemap aspect... just based on what chas has
asked about RBAC before, I can only presume he's still looking for
more granularity than sitemap offers :-)
Perhaps it might work for Glenn though...
Cheers, Tim
On Sep 6, 3:44 pm, "marius d." wrote:
> Glen,
>
> Tim is correct however HTTP auth support + it's Role model can be used
> for SiteMenu as well. Please see:
>
> case class HttpAuthProtected(role: () => Box[Role]) extends LocParam
>
> You easily can specify that a Loc is a protected resource you just
> need to return the Role that guards this resource. This Loc will be
> served only if HTTP authentication succeeds and the Role match.
>
> So this is an RBAC.
>
> Br's,
> Marius
>
> On Sep 5, 7:57 pm, Timothy Perrett wrote:
>
>
>
> > Glenn, its simply not designed to do what your asking - however, the
> > most "lift way" of doing access control is with SiteMap, so
> > potentially look into that as a solution. You don't detail your needs,
> > but we've had this conversation several times on-list so just look
> > through the archives and that might spawn some other ideas for you.
>
> > Tim
>
> > PS: Is there any good reason you always put an ellipsis after your
> > name? For some reason it bothers me quite a bit!
>
> > On Sep 5, 5:32 pm, glenn wrote:
>
> > > Marius,
>
> > > I appreciate your reply, but the question I asked regards useage of
> > > the Role trait in what Charles
> > > refers to as a Role-Based Access Control (RBAC) system. I could not
> > > find this addressed in the
> > > Lift Book and, no, there is no illuminating code in the lift-
> > > authentication example. It's established
> > > the trait is not a good mixin for a mapper class in maintaining
> > > persistent role/access
> > > data. I was asking, on a lark, if anyone had ideas on a pattern that
> > > might help. I guess
> > > I've gotten an answer - No.
>
> > > I certainly don't expect Lift, out-of-the-box, to provide a complete
> > > authorization package
> > > and I would have been surprised if it had.
>
> > > Glenn...
>
> > > On Sep 5, 12:38 am, "marius d." wrote:
>
> > > > I'll let Tim provide you a concrete code example but AFAIK there is a
> > > > lift-authetication example in examples?
>
> > > > A few points:
>
> > > > 1. We support both BASIC and DIGEST HTTP authentication
> > > > 2. First, to apply authentication you need to specify which resource
> > > > (by URI) is a protected resource. Here we say that resource X is
> > > > protected by Role A (Roles are hierarchicaly structured)
> > > > 3. Secondly you set up the authentication function in Boot (for Basic
> > > > or Digest) you check the credentials. If authentication succeeds that
> > > > request is being processed.
>
> > > > Here is an example from lift-authentication:
>
> > > > LiftRules.httpAuthProtectedResource.prepend {
> > > > case (ParsePath("secure-basic" :: Nil, _, _, _)) =>
> > > > Full(AuthRole("admin"))
> > > > }
> > > > // This resource is protected by an AuthRole named admin.
>
> > > > LiftRules.authentication = HttpBasicAuthentication("lift") {
> > > > case ("someuser", "1234", req) => {
> > > > Log.info("You are now authenticated !")
> > > > userRoles(AuthRole("admin"))
> > > > true
> > > > }
> > > > }
>
> > > > When we try to access /secure-basic resource HTTP basic auth. is
> > > > applied. If
> > > > credentials are correct we set the AuthRole as admin on the
> > > > Requestvar
> > > > userRoles. If we would have set another role such as userRoles
> > > > (AuthRole
> > > > ("guest")) the resource would still not be served as guest has nothing
> > > > to do with
> > > > an admin. The lift-book describes the rules of Roles application.
>
> > > > All this has nothing to do with Mapper or Record etc. it is purely
> > > > about HTTP authentication and a simple authorization mechanism
>
> > > > Br's,
> > > > Marius
>
> > > > On Sep 5, 12:53 am, glenn 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...
--~--~--
[Lift] Re: Using Roles and LIftRules.authentication
Glen,
Tim is correct however HTTP auth support + it's Role model can be used
for SiteMenu as well. Please see:
case class HttpAuthProtected(role: () => Box[Role]) extends LocParam
You easily can specify that a Loc is a protected resource you just
need to return the Role that guards this resource. This Loc will be
served only if HTTP authentication succeeds and the Role match.
So this is an RBAC.
Br's,
Marius
On Sep 5, 7:57 pm, Timothy Perrett wrote:
> Glenn, its simply not designed to do what your asking - however, the
> most "lift way" of doing access control is with SiteMap, so
> potentially look into that as a solution. You don't detail your needs,
> but we've had this conversation several times on-list so just look
> through the archives and that might spawn some other ideas for you.
>
> Tim
>
> PS: Is there any good reason you always put an ellipsis after your
> name? For some reason it bothers me quite a bit!
>
> On Sep 5, 5:32 pm, glenn wrote:
>
> > Marius,
>
> > I appreciate your reply, but the question I asked regards useage of
> > the Role trait in what Charles
> > refers to as a Role-Based Access Control (RBAC) system. I could not
> > find this addressed in the
> > Lift Book and, no, there is no illuminating code in the lift-
> > authentication example. It's established
> > the trait is not a good mixin for a mapper class in maintaining
> > persistent role/access
> > data. I was asking, on a lark, if anyone had ideas on a pattern that
> > might help. I guess
> > I've gotten an answer - No.
>
> > I certainly don't expect Lift, out-of-the-box, to provide a complete
> > authorization package
> > and I would have been surprised if it had.
>
> > Glenn...
>
> > On Sep 5, 12:38 am, "marius d." wrote:
>
> > > I'll let Tim provide you a concrete code example but AFAIK there is a
> > > lift-authetication example in examples?
>
> > > A few points:
>
> > > 1. We support both BASIC and DIGEST HTTP authentication
> > > 2. First, to apply authentication you need to specify which resource
> > > (by URI) is a protected resource. Here we say that resource X is
> > > protected by Role A (Roles are hierarchicaly structured)
> > > 3. Secondly you set up the authentication function in Boot (for Basic
> > > or Digest) you check the credentials. If authentication succeeds that
> > > request is being processed.
>
> > > Here is an example from lift-authentication:
>
> > > LiftRules.httpAuthProtectedResource.prepend {
> > > case (ParsePath("secure-basic" :: Nil, _, _, _)) =>
> > > Full(AuthRole("admin"))
> > > }
> > > // This resource is protected by an AuthRole named admin.
>
> > > LiftRules.authentication = HttpBasicAuthentication("lift") {
> > > case ("someuser", "1234", req) => {
> > > Log.info("You are now authenticated !")
> > > userRoles(AuthRole("admin"))
> > > true
> > > }
> > > }
>
> > > When we try to access /secure-basic resource HTTP basic auth. is
> > > applied. If
> > > credentials are correct we set the AuthRole as admin on the
> > > Requestvar
> > > userRoles. If we would have set another role such as userRoles
> > > (AuthRole
> > > ("guest")) the resource would still not be served as guest has nothing
> > > to do with
> > > an admin. The lift-book describes the rules of Roles application.
>
> > > All this has nothing to do with Mapper or Record etc. it is purely
> > > about HTTP authentication and a simple authorization mechanism
>
> > > Br's,
> > > Marius
>
> > > On Sep 5, 12:53 am, glenn 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
-~--~~~~--~~--~--~---
[Lift] Re: Using Roles and LIftRules.authentication
Glenn, its simply not designed to do what your asking - however, the
most "lift way" of doing access control is with SiteMap, so
potentially look into that as a solution. You don't detail your needs,
but we've had this conversation several times on-list so just look
through the archives and that might spawn some other ideas for you.
Tim
PS: Is there any good reason you always put an ellipsis after your
name? For some reason it bothers me quite a bit!
On Sep 5, 5:32 pm, glenn wrote:
> Marius,
>
> I appreciate your reply, but the question I asked regards useage of
> the Role trait in what Charles
> refers to as a Role-Based Access Control (RBAC) system. I could not
> find this addressed in the
> Lift Book and, no, there is no illuminating code in the lift-
> authentication example. It's established
> the trait is not a good mixin for a mapper class in maintaining
> persistent role/access
> data. I was asking, on a lark, if anyone had ideas on a pattern that
> might help. I guess
> I've gotten an answer - No.
>
> I certainly don't expect Lift, out-of-the-box, to provide a complete
> authorization package
> and I would have been surprised if it had.
>
> Glenn...
>
> On Sep 5, 12:38 am, "marius d." wrote:
>
>
>
> > I'll let Tim provide you a concrete code example but AFAIK there is a
> > lift-authetication example in examples?
>
> > A few points:
>
> > 1. We support both BASIC and DIGEST HTTP authentication
> > 2. First, to apply authentication you need to specify which resource
> > (by URI) is a protected resource. Here we say that resource X is
> > protected by Role A (Roles are hierarchicaly structured)
> > 3. Secondly you set up the authentication function in Boot (for Basic
> > or Digest) you check the credentials. If authentication succeeds that
> > request is being processed.
>
> > Here is an example from lift-authentication:
>
> > LiftRules.httpAuthProtectedResource.prepend {
> > case (ParsePath("secure-basic" :: Nil, _, _, _)) =>
> > Full(AuthRole("admin"))
> > }
> > // This resource is protected by an AuthRole named admin.
>
> > LiftRules.authentication = HttpBasicAuthentication("lift") {
> > case ("someuser", "1234", req) => {
> > Log.info("You are now authenticated !")
> > userRoles(AuthRole("admin"))
> > true
> > }
> > }
>
> > When we try to access /secure-basic resource HTTP basic auth. is
> > applied. If
> > credentials are correct we set the AuthRole as admin on the
> > Requestvar
> > userRoles. If we would have set another role such as userRoles
> > (AuthRole
> > ("guest")) the resource would still not be served as guest has nothing
> > to do with
> > an admin. The lift-book describes the rules of Roles application.
>
> > All this has nothing to do with Mapper or Record etc. it is purely
> > about HTTP authentication and a simple authorization mechanism
>
> > Br's,
> > Marius
>
> > On Sep 5, 12:53 am, glenn 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
-~--~~~~--~~--~--~---
[Lift] Re: Using Roles and LIftRules.authentication
Marius,
I appreciate your reply, but the question I asked regards useage of
the Role trait in what Charles
refers to as a Role-Based Access Control (RBAC) system. I could not
find this addressed in the
Lift Book and, no, there is no illuminating code in the lift-
authentication example. It's established
the trait is not a good mixin for a mapper class in maintaining
persistent role/access
data. I was asking, on a lark, if anyone had ideas on a pattern that
might help. I guess
I've gotten an answer - No.
I certainly don't expect Lift, out-of-the-box, to provide a complete
authorization package
and I would have been surprised if it had.
Glenn...
On Sep 5, 12:38 am, "marius d." wrote:
> I'll let Tim provide you a concrete code example but AFAIK there is a
> lift-authetication example in examples?
>
> A few points:
>
> 1. We support both BASIC and DIGEST HTTP authentication
> 2. First, to apply authentication you need to specify which resource
> (by URI) is a protected resource. Here we say that resource X is
> protected by Role A (Roles are hierarchicaly structured)
> 3. Secondly you set up the authentication function in Boot (for Basic
> or Digest) you check the credentials. If authentication succeeds that
> request is being processed.
>
> Here is an example from lift-authentication:
>
> LiftRules.httpAuthProtectedResource.prepend {
> case (ParsePath("secure-basic" :: Nil, _, _, _)) =>
> Full(AuthRole("admin"))
> }
> // This resource is protected by an AuthRole named admin.
>
> LiftRules.authentication = HttpBasicAuthentication("lift") {
> case ("someuser", "1234", req) => {
> Log.info("You are now authenticated !")
> userRoles(AuthRole("admin"))
> true
> }
> }
>
> When we try to access /secure-basic resource HTTP basic auth. is
> applied. If
> credentials are correct we set the AuthRole as admin on the
> Requestvar
> userRoles. If we would have set another role such as userRoles
> (AuthRole
> ("guest")) the resource would still not be served as guest has nothing
> to do with
> an admin. The lift-book describes the rules of Roles application.
>
> All this has nothing to do with Mapper or Record etc. it is purely
> about HTTP authentication and a simple authorization mechanism
>
> Br's,
> Marius
>
> On Sep 5, 12:53 am, glenn 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
-~--~~~~--~~--~--~---
[Lift] Re: Using Roles and LIftRules.authentication
On Sep 5, 12:38 am, "marius d." wrote:
> I'll let Tim provide you a concrete code example but AFAIK there is a
> lift-authetication example in examples?
>
> A few points:
>
> 1. We support both BASIC and DIGEST HTTP authentication
> 2. First, to apply authentication you need to specify which resource
> (by URI) is a protected resource. Here we say that resource X is
> protected by Role A (Roles are hierarchicaly structured)
> 3. Secondly you set up the authentication function in Boot (for Basic
> or Digest) you check the credentials. If authentication succeeds that
> request is being processed.
>
> Here is an example from lift-authentication:
>
> LiftRules.httpAuthProtectedResource.prepend {
> case (ParsePath("secure-basic" :: Nil, _, _, _)) =>
> Full(AuthRole("admin"))
> }
> // This resource is protected by an AuthRole named admin.
>
> LiftRules.authentication = HttpBasicAuthentication("lift") {
> case ("someuser", "1234", req) => {
> Log.info("You are now authenticated !")
> userRoles(AuthRole("admin"))
> true
> }
> }
>
> When we try to access /secure-basic resource HTTP basic auth. is
> applied. If
> credentials are correct we set the AuthRole as admin on the
> Requestvar
> userRoles. If we would have set another role such as userRoles
> (AuthRole
> ("guest")) the resource would still not be served as guest has nothing
> to do with
> an admin. The lift-book describes the rules of Roles application.
>
> All this has nothing to do with Mapper or Record etc. it is purely
> about HTTP authentication and a simple authorization mechanism
>
> Br's,
> Marius
>
> On Sep 5, 12:53 am, glenn 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
-~--~~~~--~~--~--~---
[Lift] Re: Using Roles and LIftRules.authentication
I'll let Tim provide you a concrete code example but AFAIK there is a
lift-authetication example in examples?
A few points:
1. We support both BASIC and DIGEST HTTP authentication
2. First, to apply authentication you need to specify which resource
(by URI) is a protected resource. Here we say that resource X is
protected by Role A (Roles are hierarchicaly structured)
3. Secondly you set up the authentication function in Boot (for Basic
or Digest) you check the credentials. If authentication succeeds that
request is being processed.
Here is an example from lift-authentication:
LiftRules.httpAuthProtectedResource.prepend {
case (ParsePath("secure-basic" :: Nil, _, _, _)) =>
Full(AuthRole("admin"))
}
// This resource is protected by an AuthRole named admin.
LiftRules.authentication = HttpBasicAuthentication("lift") {
case ("someuser", "1234", req) => {
Log.info("You are now authenticated !")
userRoles(AuthRole("admin"))
true
}
}
When we try to access /secure-basic resource HTTP basic auth. is
applied. If
credentials are correct we set the AuthRole as admin on the
Requestvar
userRoles. If we would have set another role such as userRoles
(AuthRole
("guest")) the resource would still not be served as guest has nothing
to do with
an admin. The lift-book describes the rules of Roles application.
All this has nothing to do with Mapper or Record etc. it is purely
about HTTP authentication and a simple authorization mechanism
Br's,
Marius
On Sep 5, 12:53 am, glenn 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
-~--~~~~--~~--~--~---
[Lift] Re: Using Roles and LIftRules.authentication
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 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 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 -~--~~~~--~~--~--~---
[Lift] Re: Using Roles and LIftRules.authentication
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 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 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 -~--~~~~--~~--~--~---
[Lift] Re: Using Roles and LIftRules.authentication
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 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 -~--~~~~--~~--~--~---
