Menu
▾
▴
phpwebsite-developers — For our development team.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(1) |
Mar
(265) |
Apr
(166) |
May
(25) |
Jun
(17) |
Jul
(20) |
Aug
(47) |
Sep
(6) |
Oct
(14) |
Nov
(66) |
Dec
(64) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(109) |
Feb
(64) |
Mar
(34) |
Apr
(23) |
May
(64) |
Jun
(9) |
Jul
(13) |
Aug
(6) |
Sep
(33) |
Oct
(272) |
Nov
(67) |
Dec
(75) |
| 2003 |
Jan
(264) |
Feb
(244) |
Mar
(171) |
Apr
(119) |
May
(54) |
Jun
(93) |
Jul
(51) |
Aug
(48) |
Sep
(14) |
Oct
(49) |
Nov
(47) |
Dec
(15) |
| 2004 |
Jan
(13) |
Feb
(27) |
Mar
(18) |
Apr
(44) |
May
(35) |
Jun
(24) |
Jul
(39) |
Aug
(142) |
Sep
(35) |
Oct
(34) |
Nov
(49) |
Dec
(24) |
| 2005 |
Jan
(60) |
Feb
(71) |
Mar
(19) |
Apr
(27) |
May
(68) |
Jun
(4) |
Jul
(30) |
Aug
(10) |
Sep
(23) |
Oct
(24) |
Nov
(13) |
Dec
(6) |
| 2006 |
Jan
(4) |
Feb
(46) |
Mar
(64) |
Apr
(18) |
May
(16) |
Jun
(37) |
Jul
(7) |
Aug
(19) |
Sep
(9) |
Oct
(8) |
Nov
(3) |
Dec
(23) |
| 2007 |
Jan
(25) |
Feb
(21) |
Mar
(32) |
Apr
(36) |
May
(12) |
Jun
(1) |
Jul
(7) |
Aug
(15) |
Sep
(13) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
(3) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(7) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(7) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: <re...@ki...> - 2005-03-05 10:25:21
|
Hi! =20 =20 My practical training for my master study will be (basically) about = moving organizations away from classic black boards to the web. The plan: Every organization gets their phpwebsite installation (a branch) and will be automatically listed on a master installation (the main phpwebsite installation). =20 That's the tricky part. There is a place for the site name, which I will reuse as the organization name. I can list that quite easily on the master-site. But is there a standarized place for meta-data as well? = Take for example a doctors-organization. It has, say, 20 members. =20 These members have certain attributes. Like opening-times, = qualifications, etc. =20 Where would I put that? I'd put it somewhere in the branches, these informations would have to be editable by the branch-owners. Still, I = need a (searchable) list on the master site. And also some kind of advanced = search (on a per-field basis), which doesn't seem to exist yet. =20 =20 regards, =20 Ren=E9! |
|
From: <re...@ki...> - 2005-03-04 19:06:02
|
Hi! I'd like to share a quick thought I'm having for quite some time. How about having 'dynamic icons' in the controlpanel? Some examples: - the clock module icon could represent the current time (drawn with gd that shouldn't be too hard) - the approval-icon could be green, when there's something to approve. black otherwise. - the notes icon could have the number of new notes superimposed on it etc. |
|
From: Brady B. <bra...@gm...> - 2005-03-02 19:35:25
|
Thanks. I patched my site. I had originally sent out this question before a patch was issued...not sure why it's just showing up now. Thanks again, Brady On Wed, 02 Mar 2005 11:31:55 -0500, Jim Wilson <spi...@us...> wrote: > > From: Brady Bellinger > > > > Are sites that only allow trusted, registered users also affected by > this issue? > > To my knowledge our site does not allow anonymous users to submit > announcements. > > > > Thanks, > > > > Brady > > Hi Brady, > > That might make a little bit of difference, but this is serious enough > that you should do > the patch. If you are running and older version or have a heavily > modified installation, > just add the new code in index.php to your index.php. > > Also do not be fooled by comments such as "normally only apache/nobody > user access is attained". > Such access is the first step of almost all breakins as it gives enough > access to run a privelege escallation exploit. > > I would like to hear some other opinions on this as well, but that's > currently my take on > the situation. > > Best regards, > > Jim Wilson > > > ------------------------------------------------------- > 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=6595&alloc_id=14396&op=click > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > -- To send me encrypted email or verify my signature, my public key is available <a href="http://bradybellinger.com/brady.asc">here</a>. |
|
From: Jim W. <spi...@us...> - 2005-03-02 18:59:39
|
> From: Brady Bellinger > > Are sites that only allow trusted, registered users also affected by this issue? > To my knowledge our site does not allow anonymous users to submit announcements. > > Thanks, > > Brady Hi Brady, That might make a little bit of difference, but this is serious enough that you should do the patch. If you are running and older version or have a heavily modified installation, just add the new code in index.php to your index.php. Also do not be fooled by comments such as "normally only apache/nobody user access is attained". Such access is the first step of almost all breakins as it gives enough access to run a privelege escallation exploit. I would like to hear some other opinions on this as well, but that's currently my take on the situation. Best regards, Jim Wilson |
|
From: Steven L. <st...@tu...> - 2005-03-02 17:14:35
|
On Wed, 2005-03-02 at 16:47 +0100, Sander van den Broek wrote:
> I got this form element:
>
> <code>
> $rub = array();
> $rub[]=NULL;
> $rub['1']="String1";
> $rub['2']="String2";
> $rub['3']="String3";
> $rub['4']="String4";
> $rub['5']="String5";
>
> $form->add('catrubriek', 'select', $rub);
> </code>
>
> I want the form to select value "$this->_thisrub" as a default in the
> select-element.
>
> How can this be done?
$form->setMatch('catrubriek', $this->_thisrub);
--
Steven
|
|
From: Shaun M. <sh...@ae...> - 2005-03-02 16:30:27
|
On 25 Feb 2005, at 18:36, Brady Bellinger wrote: > Are sites that only allow trusted, registered users also affected by > this issue? > To my knowledge our site does not allow anonymous users to submit > announcements. > Even anonymous users have access to the announcement submission page. http://www.yoursite.com/index.php? module=announce&ANN_user_op=submit_announcement Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Sander v. d. B. <sa...@sa...> - 2005-03-02 15:47:44
|
I got this form element:
<code>
$rub = array();
$rub[]=NULL;
$rub['1']="String1";
$rub['2']="String2";
$rub['3']="String3";
$rub['4']="String4";
$rub['5']="String5";
$form->add('catrubriek', 'select', $rub);
</code>
I want the form to select value "$this->_thisrub" as a default in the
select-element.
How can this be done?
Best regards,
Sander van den Broek
|
|
From: Matthew M. <ma...@tu...> - 2005-03-01 14:50:42
|
Just a reminder, If you haven't updated your copy of phpwebsite with the new patch, please visit our home page and grab a copy. The patch was updated yesterday with some bug fixes. -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2005-02-28 13:59:18
|
Remove it entirely. This was left in by accident during testing. On Sat, 2005-02-26 at 10:21 -0500, Jim Wilson wrote: > I hope your branches are still working (Or how about the most basic > regression > testing before comitting to cvs and announcing fixes on the internet > ;-)) > > An easy one to miss and glad I remembered to check this time! The > following > edit around line 163 or so will fix it: > > Change > > require_once './core/Debug.php'; > > to > require_once $hub_dir . '/core/Debug.php'; > > > Otherwise patch works great. Thanks for the quick fix on this. > > Best regards, > > Jim Wilson > > > From: Matthew McNaney > > > > We have created an updated patch. > > > http://phpwebsite.appstate.edu/downloads/security/phpws_files_security_p > atch.tgz > > > > It contains the search fix and a new function in the index.php that > > scrubs ANY uploaded file. This fix should work for all modules. > > > > The calendar and announcement patch file are still on the site. > > > > Thank you for your patience with this issue. > > > > -- > > Matthew McNaney > > Electronic Student Services > > Appalachian State University > > http://phpwebsite.appstate.edu > > > > > ------------------------------------------------------- > 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=6595&alloc_id=14396&op=click > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2005-02-28 13:58:23
|
Yes. We will have a new release hopefully this week. I would work on today but Steven normally does it and I don't want to muck anything up trying to do it myself. We are shorthanded today after a blizzard. On Sat, 2005-02-26 at 12:15 -0700, Greg Morgan wrote: > Matthew McNaney wrote: > > Please download and untar in your phpwebsite installation directory. > > > > http://phpwebsite.appstate.edu/downloads/security/phpws_image_secure_patch.tgz > > I thought there was another security release some time ago. Is it time > to release 0.10.1 with these patches and any other bug fixes that have > been accrued? > > Greg > > > ------------------------------------------------------- > 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=6595&alloc_id=14396&op=click > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Jim W. <spi...@us...> - 2005-02-27 18:23:11
|
Hi Wendall, Sure I know all this having written many bugs myself. The "wink" modicon and=20 reference to "most basic" was just to say maybe simply trying to access a branch=20 site once would've caught it. But I also said, "An easy one to miss and glad I remembered to check this time!" In fact I mistyped the recommended fix in my=20 earlier email! It was incorrect and did not match what I actually did to the code here. Mistakes happen. BTW...for readers...the correction is elsewhere in this thread. So no criticism intended. In fact as I said before, the quick response on this=20 issue is very much appreciated. Thanks, Jim > From: wendall >=20 > Jim, >=20 > The issue was that somebody posted this exploit to a public list without > letting the development team know. When things like this happen, > regression testing isn't possible. Unless you'd like to wait a few days > for security releases that are in the wild. Regression testing is fine for > normal things. All fixes are announced on the internet as well. Either > through the bug tracker on sf.net or with new releases. Spend the time and > write all regression tests and I'm sure they'd be considered. If you > understand the nature of cvs commits, you'd know that only released code > gets tested. The cvs repository can and often contains bugs. Or sometimes > doesn't work at all. The primary purpose of cvs isn't for building > functional code. That's what release processes are for. There will have to > be alot more testing on the latest fix before it is finalized. It was a > hack to get things protected for users. There will be more work on this > and a more formally tested release given. >=20 > Wendall >=20 > > On Sat, 2005-02-26 at 07:21, Jim Wilson wrote: > >> how about the most basic regression testing before comitting to cvs and > >> announcing fixes on the internet > > > > Jim, > > I've advocated Unit Testing for that, but the developers don't think > > it's a worthwhile idea. > > > > > > Functional testing, Performance testing, HTML testing, and PHP > > testing > > > > http://opensourcetesting.org/ > > > > -- > > Mike Noyes <mhnoyes at users.sourceforge.net> > > http://sourceforge.net/users/mhnoyes/ > > SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs > > > > > > > > ------------------------------------------------------- > > 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 > >=20 > > Phpwebsite-developers mailing list > > Php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > >=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_ide95&alloc_id=14396&op=CCk >=20 > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers >=20 |
|
From: Ken N. <ke...@co...> - 2005-02-27 15:03:26
|
On Sat, 2005-02-26 at 10:21 -0500, Jim Wilson wrote: <snip> > Change > require_once './core/Debug.php'; > to > require_once $hub_dir . '/core/Debug.php'; </snip> The change should actually be: require_once $hub_dir . 'core/Debug.php'; Sans the leading / in front of core. Regards, Ken -- Ken Nordquist "Community Marketing for the Next Generation" Call Us Toll Free: 866-621-4043 http://communitygems.com |
|
From: <wen...@to...> - 2005-02-27 02:39:34
|
Jim, The issue was that somebody posted this exploit to a public list without letting the development team know. When things like this happen, regression testing isn't possible. Unless you'd like to wait a few days for security releases that are in the wild. Regression testing is fine fo= r normal things. All fixes are announced on the internet as well. Either through the bug tracker on sf.net or with new releases. Spend the time an= d write all regression tests and I'm sure they'd be considered. If you understand the nature of cvs commits, you'd know that only released code gets tested. The cvs repository can and often contains bugs. Or sometimes doesn't work at all. The primary purpose of cvs isn't for building functional code. That's what release processes are for. There will have t= o be alot more testing on the latest fix before it is finalized. It was a hack to get things protected for users. There will be more work on this and a more formally tested release given. Wendall > On Sat, 2005-02-26 at 07:21, Jim Wilson wrote: >> how about the most basic regression testing before comitting to cvs an= d >> announcing fixes on the internet > > Jim, > I've advocated Unit Testing for that, but the developers don't think > it's a worthwhile idea. > > > Functional testing, Performance testing, HTML testing, and PHP > testing > > http://opensourcetesting.org/ > > -- > Mike Noyes <mhnoyes at users.sourceforge.net> > http://sourceforge.net/users/mhnoyes/ > SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs > > > > ------------------------------------------------------- > 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 > |
|
From: Greg M. <drk...@co...> - 2005-02-26 21:58:38
|
Shaun Murray wrote: > > On 26 Feb 2005, at 19:15, Greg Morgan wrote: > >> Matthew McNaney wrote: >> >>> Please download and untar in your phpwebsite installation directory. >>> http://phpwebsite.appstate.edu/downloads/security/ >>> phpws_image_secure_patch.tgz >> >> >> I thought there was another security release some time ago. Is it >> time to release 0.10.1 with these patches and any other bug fixes >> that have been accrued? > > > I think the only changes in cvs since 0.10.0 have been these security > changes and a template change in pagemaster so it would usually be a > little early for a 0.10.1 release although it's perhaps important now > for new users so that they don't install 0.10.0 without the security > patch. > > > Shaun > aegis design - http://www.aegisdesign.co.uk I am wondering what the best solution is based on the skill of some users in the forum? For example, even though there is information on unzipping modules and themes here http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Third_Party_Module_Installation http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Third_Party_Theme_Installation_Guide I don't many users will make the connection. If we say go to cvs for the updates and use this documentation http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Maintenance_Guide that may be too involved for most users. Saying please upgrade to this 0.10.1 security release using this documentation http://phpwebsite-comm.sourceforge.net/wiki/index.php?title=Upgrade_Guide may be the safest best. Then again why am I concerned about this? There's enough people that don't follow updates for the software they use that phpWebSite will still get the bad press for the problem even though there was a quick resolution by ASU. Thankfully, we didn't have to wait for the commercial vendor 12 steps: denial of the issue, committee investigation of the issue, development of the mission statement concerning the issue, lower the risk of the issue, corporate spin doctoring the issue, the announcement that it will be with the next monthly patch, think about creating the patch, ... Greg |
|
From: Shaun M. <sh...@ae...> - 2005-02-26 20:20:01
|
On 26 Feb 2005, at 19:15, Greg Morgan wrote: > Matthew McNaney wrote: >> Please download and untar in your phpwebsite installation directory. >> http://phpwebsite.appstate.edu/downloads/security/ >> phpws_image_secure_patch.tgz > > I thought there was another security release some time ago. Is it > time to release 0.10.1 with these patches and any other bug fixes that > have been accrued? I think the only changes in cvs since 0.10.0 have been these security changes and a template change in pagemaster so it would usually be a little early for a 0.10.1 release although it's perhaps important now for new users so that they don't install 0.10.0 without the security patch. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Greg M. <drk...@co...> - 2005-02-26 19:16:17
|
Matthew McNaney wrote: > Please download and untar in your phpwebsite installation directory. > > http://phpwebsite.appstate.edu/downloads/security/phpws_image_secure_patch.tgz I thought there was another security release some time ago. Is it time to release 0.10.1 with these patches and any other bug fixes that have been accrued? Greg |
|
From: Mike N. <mh...@us...> - 2005-02-26 17:56:16
|
On Sat, 2005-02-26 at 07:21, Jim Wilson wrote:
> how about the most basic regression testing before comitting to cvs and
> announcing fixes on the internet
Jim,
I've advocated Unit Testing for that, but the developers don't think
it's a worthwhile idea.
Functional testing, Performance testing, HTML testing, and PHP
testing
http://opensourcetesting.org/
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
|
|
From: Jim W. <spi...@us...> - 2005-02-26 15:23:13
|
I hope your branches are still working (Or how about the most basic regression testing before comitting to cvs and announcing fixes on the internet ;-)) An easy one to miss and glad I remembered to check this time! The following edit around line 163 or so will fix it: Change require_once './core/Debug.php'; to require_once $hub_dir . '/core/Debug.php'; Otherwise patch works great. Thanks for the quick fix on this. Best regards, Jim Wilson From: Matthew McNaney > > We have created an updated patch. > http://phpwebsite.appstate.edu/downloads/security/phpws_files_security_p atch.tgz > > It contains the search fix and a new function in the index.php that > scrubs ANY uploaded file. This fix should work for all modules. > > The calendar and announcement patch file are still on the site. > > Thank you for your patience with this issue. > > -- > Matthew McNaney > Electronic Student Services > Appalachian State University > http://phpwebsite.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2005-02-25 23:09:07
|
We have created an updated patch. http://phpwebsite.appstate.edu/downloads/security/phpws_files_security_patch.tgz It contains the search fix and a new function in the index.php that scrubs ANY uploaded file. This fix should work for all modules. The calendar and announcement patch file are still on the site. Thank you for your patience with this issue. -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2005-02-25 19:53:56
|
Please download and untar in your phpwebsite installation directory. http://phpwebsite.appstate.edu/downloads/security/phpws_image_secure_patch.tgz -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Brady B. <bra...@gm...> - 2005-02-25 18:36:07
|
Are sites that only allow trusted, registered users also affected by this issue? To my knowledge our site does not allow anonymous users to submit announcements. Thanks, Brady On Fri, 25 Feb 2005 11:01:59 -0500, Matthew McNaney <ma...@tu...> wrote: > The security problem is serious. You can change your MIME type to > disguise the file. > > Shut down your announcement modules NOW. We are investigating this issue > further. > > -- > Matthew McNaney > Electronic Student Services > Appalachian State University > http://phpwebsite.appstate.edu > > ------------------------------------------------------- > 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=6595&alloc_id=14396&op=click > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > -- To send me encrypted email or verify my signature, my public key is available <a href="http://bradybellinger.com/brady.asc">here</a>. |
|
From: Matthew M. <ma...@tu...> - 2005-02-25 16:28:55
|
ANY module that allows image uploads is vulnerable. Make sure to disable calendar's user submitted events. If you want to retain functionality, you will need to comment out the form and save functions for image uploads. -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2005-02-25 16:13:35
|
The security problem is serious. You can change your MIME type to disguise the file. Shut down your announcement modules NOW. We are investigating this issue further. -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Matthew M. <ma...@tu...> - 2005-02-25 15:18:44
|
Thanks Wendall. Steven and I tested it this morning and had the same results. Unless php is set as a image type, it won't go. However, I don't want to be too cocky. I received an email from someone who claimed they had some sites hacked. If anyone is able to reproduce this exploit, please email us. Thanks, Matt and Steven On Thu, 2005-02-24 at 16:26 -0800, Wendall Cada wrote: > Hey all. There was a security announcement on BUGTRAQ > http://www.securityfocus.com/archive/1/391496/2005-02-21/2005-02-27/0 > > I tested and it is invalid. It can be exploited if you change the > settings to allow for uploading of php files, which the submitter failed > to mention. He also failed to mention OS/Server/PHP version as well. > Maybe this does work on Personal Web Server for Windows 95, dunno. This > should at least be a good example of why phpWebSite will never be > permitted to insert code for any reason or in any form through the > interface. > > Not sure how you want to respond to this Matt, but since it's already > all over the internet, I'll just post it here and leave it up to you. > > Wendall > > > ------------------------------------------------------- > 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=6595&alloc_id=14396&op=click > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
|
From: Greg T. <gt-...@ta...> - 2005-02-25 09:39:47
|
I've finally prepared an initial patch for the disabling of user accounts. It is simple but effective, and pretty clean. For details please see the Patch Tracker: https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1151625&group= _id=3D15539&atid=3D315539 Let me know if you have any questions. Greg T. On Fri, 2005-02-18 at 23:56 -0800, Greg Tassone wrote: > 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. >=20 > 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. >=20 > 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. >=20 > I'll post back on the results and patch availability in case anyone else > wants to use this functionality. >=20 > Thanks again! >=20 > Greg T. >=20 >=20 > 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 w= hen > > > 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 coul= d > > > 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/br= eak > > > 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 twe= ak > > > the security module. On every security check we could examine the us= er > > > account for a "disabled" status, and if the user was disabled the > > > security check would always return false. This would probably be sim= ple > > > 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 t= his > > > 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 |
5 messages has been excluded from this view by a project administrator.
