Thread: [Userlogin-users] Re: userlogin
Status: Beta
Brought to you by:
johnkeiser
From: John K. <jk...@in...> - 2001-09-06 17:47:00
|
Incidentally all, 0.6.2 is out with a bugfix in permissions checking. On 06 Sep 2001 11:20:53 -0400, la...@lu... wrote: > > Hello all. I recently ran into the UserLogin component(s) for mason, and > have one question about it. I have it set up and working, but the > documentation is a little sparse (non existant? :) ). > Besides the comments in autohandler and the install guide, none. Soon, I promise :) BTW, the proper place for this use...@so... ... I'd like to pollute the Mason list as little as possible with my bugs. You might want to grab the new version I just put up (0.6.2) which fixes the $sys->finished thing and makes the example permissions stuff look better. Answers below. > I'm unclear about one of the overrideable things in the autohandler. The > permissions attribute has me confused. > > First of all, the example attributes in the included autohandler in the > sample application looks wrong. It has: > > <%attr> > $permissions=> { "Cannot Do Anything" => 0, "Super-User" => 1} > </%attr> > > Shouldn't that be "permissions=>" instead? > Yeppers. And the <%doc> around it needs to be removed. In fact, you don't need either of those statements--they are redundant. The default check_permissions checks those no matter what. And you're right about the ->finished thing, I apparently didn't retest permissions hash after changing %cleanup. The new version fixes the error. For the situation you described, this boolean checking won't help you anyway, so you don't need to grab it yet. Read on. > Does anyone have a good working example on what I need to do to specify in > a component / page that it can only be accessed by someone at or above a > specific user level using UserLogin? > Since the default check_session only checks boolean, you'll have to override check_permissions. Search for %method check_permissions in autohandler. Remove the %doc around it. For what you're looking for, check_permissions is your best bet. Here's an example. You can override this in different components to use different levels. <%method check_permissions> <%perl> my $user = $ARGS{-sys}{users}{$ARGS{-session}{_user_id}}; if($user->{UserLevel} < 5) { return 0; } return $m->call_method("session:check_permissions", %ARGS); </%perl> </%method> You don't have to call session:check_permissions, but if you want to be able to disable users using the "Cannot Do Anything" parameter it's a good idea. --John |
From: <la...@lu...> - 2001-09-06 20:07:28
|
Thanks for the info John. By the way, is there a way to set password to be encrypted, or will I need to hack that in if I want it? ----------------------------------------------------------------------------- Brian Knox Just Another Perl Hacker perl -le '$_="6110>374086;2064208213:90<307;55";tr[0->][ LEOR!AUBGNSTY];print' On 6 Sep 2001, John Keiser wrote: > Incidentally all, 0.6.2 is out with a bugfix in permissions checking. > > > On 06 Sep 2001 11:20:53 -0400, la...@lu... wrote: > > > > Hello all. I recently ran into the UserLogin component(s) for mason, and > > have one question about it. I have it set up and working, but the > > documentation is a little sparse (non existant? :) ). > > > > Besides the comments in autohandler and the install guide, none. Soon, > I promise :) > > BTW, the proper place for this use...@so... ... I'd > like to pollute the Mason list as little as possible with my bugs. > > You might want to grab the new version I just put up (0.6.2) which fixes > the $sys->finished thing and makes the example permissions stuff look > better. Answers below. > > > I'm unclear about one of the overrideable things in the autohandler. The > > permissions attribute has me confused. > > > > First of all, the example attributes in the included autohandler in the > > sample application looks wrong. It has: > > > > <%attr> > > $permissions=> { "Cannot Do Anything" => 0, "Super-User" => 1} > > </%attr> > > > > Shouldn't that be "permissions=>" instead? > > > > Yeppers. > > And the <%doc> around it needs to be removed. In fact, you don't need > either of those statements--they are redundant. The default > check_permissions checks those no matter what. And you're right about > the ->finished thing, I apparently didn't retest permissions hash after > changing %cleanup. The new version fixes the error. > > For the situation you described, this boolean checking won't help you > anyway, so you don't need to grab it yet. Read on. > > > Does anyone have a good working example on what I need to do to specify in > > a component / page that it can only be accessed by someone at or above a > > specific user level using UserLogin? > > > > Since the default check_session only checks boolean, you'll have to > override check_permissions. Search for %method check_permissions in > autohandler. Remove the %doc around it. > > For what you're looking for, check_permissions is your best bet. > > Here's an example. You can override this in different components to use > different levels. > > <%method check_permissions> > <%perl> > my $user = $ARGS{-sys}{users}{$ARGS{-session}{_user_id}}; > if($user->{UserLevel} < 5) { > return 0; > } > > return $m->call_method("session:check_permissions", %ARGS); > </%perl> > </%method> > > You don't have to call session:check_permissions, but if you want to be > able to disable users using the "Cannot Do Anything" parameter it's a > good idea. > > --John > > > > _______________________________________________ > userlogin-users mailing list > use...@li... > https://lists.sourceforge.net/lists/listinfo/userlogin-users > |
From: John K. <jk...@in...> - 2001-09-06 20:19:01
|
On 06 Sep 2001 16:07:24 -0400, la...@lu... wrote: > Thanks for the info John. > > By the way, is there a way to set password to be encrypted, or will I need > to hack that in if I want it? > Not yet ... if you want to hack it in that'd be great :) I was thinking it would be good to keep the changes local to JavaScript (encrypt password when registering (before sending to server), encrypt password before sending to server when logging in. Then the server just has to do a compare, and as an added benefit the password is encrypted even over HTTP. The other possible way is to make the change in UserLogin.pm itself, in any place where it looks at the "-password". I figure if it can be done in JavaScript it's easier, though. See the related bug (http://sourceforge.net/tracker/index.php?func=detail&aid=457128&group_id=34123&atid=410562) for some info. --John Keiser |