Re: [Phpwebsite-developers] Banning of users

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Thanks Eloi.  I have added my +1 to the RFE.

Also, I have already coded a back-end for this by using the password
field to track a "DISABLED" status for a user.  I basically used
Wendall's suggestion, although I had to recode it a bit to work
properly.

This solution is somewhat Unix-like -- the permissions schema need not
be extended further from what I can see.  Checking the password field
for the string "DISABLED" is sufficient, and will always prevent
logging-in under that account (due to the one-way hashing already in
place).

The only thing I haven't added to my patch yet was a "switch" item to
the User edit screens.  The current "admin" flag would be a perfect way
to go, it seems.

This is an important feature that the system is missing here...
Disabling existing accounts is a key function that should be available
as a standard user scenario, IMHO.

Greg T.

On Tue, 2005-02-22 at 14:03 -0400, Eloi George wrote:
> In June 2003, Richard Sumilang suggested changing the Admin switch to an=20
> "Activate/Disable account" switch.  All the active  developers at the=20
> time supported it and the core team agreed to code it.  However, with=20
> all the extra projects they had to work on and the fact that noone ever=20
> submitted an RFE, we all just kind of forgot about it.=20
>=20
> The thread where this happened is at=20
> https://sourceforge.net/mailarchive/forum.php?thread_id=3D2898205&forum_i=
d=3D34704
>=20
> To rectify the situation, I've just submitted an RFE.=20
> https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1146448&gro=
up_id=3D15539&atid=3D365539
> I urge you all to put your "+1" on it again as an indication of our=20
> desire for this change.
>=20
> -Eloi-
>=20
>=20
> Greg Tassone wrote:
>=20
> >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:
> > =20
> >
> >>Ok, I don't know of any plans to add this, but here is a quick and
> >>dirty.
> >>
> >>Change the user password directly in the db to DENIED
> >>
> >>change line 1153 in mod/users/class/Users.php,v 1.106 from:
> >>} elseif ($_SESSION["OBJ_user"]->isDeity($user_id)) {
> >>
> >>to
> >>
> >>} 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')) {
> >>
> >>Will spit out the message:
> >>Unable to email change form.=20
> >>Please contact the systems administrator.
> >>
> >>HTH
> >>
> >>Wendall
> >>
> >>On Fri, 2005-02-18 at 02:13 -0800, Greg Tassone wrote:
> >>   =20
> >>
> >>>Good day to you all,
> >>>
> >>>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 wh=
en
> >>>an account must be "disabled" for some reason.
> >>>
> >>>We have the following goals:
> >>>
> >>>- We need to prevent users with certain accounts from being able to
> >>>login to the site.
> >>>
> >>>- 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).
> >>>
> >>>
> >>>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.
> >>>
> >>>Are there any plans for such an enhancement?  Our team was going to
> >>>write this functionality ourselves, but we don't want to duplicate/bre=
ak
> >>>something you are already planning.
> >>>
> >>>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 twea=
k
> >>>the security module.  On every security check we could examine the use=
r
> >>>account for a "disabled" status, and if the user was disabled the
> >>>security check would always return false.  This would probably be simp=
le
> >>>to add and would probably disable most/all functionality within the
> >>>site.
> >>>
> >>>However, do you have any reasons for/against?  Any better ways?  Is th=
is
> >>>already done so that I don't have to worry about it? ;-)
> >>>
> >>>Thanks in advance!
> >>>
> >>>Greg T.
> >>>
> >>>     =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
> >>   =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