From: Greg T. <gt-...@ta...> - 2005-02-19 07:56:46
|
Thanks very much. That does help. I like it -- it is simple and will do the job just fine, without messing with the DB schema or anything drastic. With this solution, no encryption hash will ever translate to a "proper" password for them, effectively disabling their account. And, with the simple line of code you contributed they will not be able to bypass the lockout with the "Forgot Password" function. I plan on coding a patch for this over the weekend. Not only will I include what you describe, but I will add a *toggle* command link ("Enable/Disable") to the User Manager that will automatically handle this. I'll probably tie it to the same permissions as the "Edit" command link. I'll post back on the results and patch availability in case anyone else wants to use this functionality. Thanks again! Greg T. On Fri, 2005-02-18 at 08:33 -0800, Wendall Cada wrote: > Ok, I don't know of any plans to add this, but here is a quick and > dirty. >=20 > Change the user password directly in the db to DENIED >=20 > change line 1153 in mod/users/class/Users.php,v 1.106 from: > } elseif ($_SESSION["OBJ_user"]->isDeity($user_id)) { >=20 > to >=20 > } elseif ($_SESSION["OBJ_user"]->isDeity($user_id) || > ($GLOBALS['core']->getRow("select password from > {$GLOBALS['core']->tbl_prefix}mod_users where user_id=3D'$user_id'") =3D= =3D > 'DENIED')) { >=20 > Will spit out the message: > Unable to email change form.=20 > Please contact the systems administrator. >=20 > HTH >=20 > Wendall >=20 > On Fri, 2005-02-18 at 02:13 -0800, Greg Tassone wrote: > > Good day to you all, > >=20 > > We have the need for user "ban" functionality within phpWebSite. To > > clarify, we want to deny registered users the ability to login. This > > usually is needed when vulgar or profane language is used, etc., or whe= n > > an account must be "disabled" for some reason. > >=20 > > We have the following goals: > >=20 > > - We need to prevent users with certain accounts from being able to > > login to the site. > >=20 > > - We need to leave their E-mail address in place; otherwise they could > > register a new user account with their same address. We just want to > > "disable" their existing account (and E-mail). > >=20 > >=20 > > At present we are changing their passwords when such things happen. > > However, if they are smart enough to use the "Lost Password" > > functionality they can get right back in. THIS IS BECOMING A BIG > > PROBLEM FOR US. > >=20 > > Are there any plans for such an enhancement? Our team was going to > > write this functionality ourselves, but we don't want to duplicate/brea= k > > something you are already planning. > >=20 > > We're not yet familiar with all parts of the architecture yet to know > > how to best accomplish this. Our initial design thoughts were to tweak > > the security module. On every security check we could examine the user > > account for a "disabled" status, and if the user was disabled the > > security check would always return false. This would probably be simpl= e > > to add and would probably disable most/all functionality within the > > site. > >=20 > > However, do you have any reasons for/against? Any better ways? Is thi= s > > already done so that I don't have to worry about it? ;-) > >=20 > > Thanks in advance! > >=20 > > Greg T. > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |