phpwebsite-developers — For our development team.

[Phpwebsite-developers] Security Announcement

[Wendall C. <wen...@to...>]

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

Re: [Phpwebsite-developers] the mod_user_uservars table

[Eloi G. <el...@re...>]

Shaun Murray wrote:

> I suspect that's because not many people know it's there!


No, we knew -- it just didn't provide that much of a benefit and 
hampered query optimization.
-Eloi-

[Phpwebsite-developers] Invitation to the mediation manual

[Robert S. <rsc...@in...>]

Dear phpWebSite developers,

I wrote some guidelines that should help FOSS projects getting more lively and lowering the barrier for new developers to join. You can find them in form of a small manual here http://projects.mi.fu-berlin.de/w/bin/view/SE/ThesisFOSSIMMediationManual.

These ideas are the result of work for my bachelor thesis and have been used successfully at the GNU Classpath project. If the topic is of interest to you, I would be happy to receive criticism and comments concerning the manual or the general idea.

For further discussion I have set up a mailing-list (use http://lists.spline.inf.fu-berlin.de/mailman/listinfo/mediation_manual to subscribe or med...@li... to post unsubscribed). Please send your feedback to this list but if you have reasons to contact me directly then just reply to this mail. In case you answer to your project's mailing list please CC me.

Best regards
Robert Schuster

Re: [Phpwebsite-developers] Banning of users

[Greg T. <gt-...@ta...>]

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

Re: [Phpwebsite-developers] the mod_user_uservars table

[<re...@ki...>]

  
> Date: Wed, 23 Feb 2005 11:44:14 +0000
> To: php...@li...
> Reply-To: php...@li...
>
> Any module can add it's own user specific variables to that 
> table. The=20=
> 
> data is serialized - go look at serialize() on php.net. If 
> you just=20 added extra columns to the table it wouldn't be 
> general purpose or=20 extendable.

> 
> You set and get them using setUserVar() and getUserVar()

Well, that I've been writing about. Add a variable "rememberme" and a
variable "language" instead of a serialized "cookie". I didn't think about
new columns, that would take away the flexibility.


> This is all in the user module developer docs.=20 
> /mod/users/docs/devdoc.txt

Thank you, will have a look into that.


On a second thought, I'll better wait on how 1.0 turns out. :-)

Let's hope, there will be less serialized stuff in it. Doing sql-joins /
filtering with serialized stuff is... almost impossible...


Rene

Re: [Phpwebsite-developers] Banning of users

[Matthew M. <ma...@tu...>]

Thanks for the response Shaun,

> I was hoping there would be a 'guest only' group so that I could put 
> blocks on the page that only non-registered users could see so that I 
> could put adverts on the page if they weren't registered and the 
> adverts would disappear if they registered.

I hadn't thought of that however it shouldn't be too hard to do that:

if (!Current_User::isRegistered()) {
  bombardWithAds();
} else {
  showEmJustTheGoodStuff();
}

So then in your item form:

() Allow everyone to see this
() ONLY allow unregistered to see this
() Only let registered see this
() Only let registered groups I pick see this

0, 1, 2, 3. You decide how to tag the item. Then the permissioning
system will help you with the rest.

Since this is a good test, I will implement this in blocks. I could
definitely see this need in that module.


> So the admin interface is ...
> 
> ( ) Everybody
> ( ) Registered users
> ( ) Specified group of users
>      [Pick group(s)]

Yes. The group interface is supplied by the Users module. You create the
radio list.

> That's better than I thought but still more complicated than it needs 
> to be IMHO and I'd still like to see a 'Guest Only' level.

Then you can make a Guest Only level (see above)


> I didn't understand the above at all but I'll proceed nonetheless ;-)

Hehe :) It is complicated and I am a poor writer. Let me try and give
some examples:

Steven comes to the site for the first time - he is an unregistered user
Matt comes to the site and logs in - he is a registered user

Shaun is member of the writing team (a registered user). Matt is the
editor. They both have permissions in the Article module.

Matt can create, edit, and delete any and every article in the module. -
He has unrestricted Article module permissions.

Shaun's submissions must be approved and he can only access articles
assigned to (or created by) him. - He has restricted permissions.

Shaun has permission to create and edit but not delete. If he did have
delete permission, he could only delete the items assigned to him
because he is a restricted user.

Shaun creates an article. Since he is restricted, it goes into the
approval queue.

Matt is unrestricted, therefore in this module he can approve and edit
Shaun's article.

Matt writes an article and posts it. Matt gives Shaun's group permission
to edit his article. Shaun can edit the article BUT the edits have to be
approved by an unrestricted person so they don't go live until someone
does so.

Yes it is complicated but item permissions do this. 

> So, from a module developers point of view, all they do is ask the 
> permission system if it's authorised content, the permission system 
> checks if there is specific item info, failing that goes with the group 
> permissions.

The module developer checks the general permissions (guest, registered,
permitted, deity) they have set for the item. They then ask the users
module if the current user fits those criteria. Is this a guest? Have
they logged in? Were they assigned the permission to alter or view this
item?

>  From an admins point of view they see a box with a list of groups, some 
> of which are real, some are predefined psuedo-groups. If they choose a 
> group an item specific entry is set, if not the system picks the module 
> defaults.

You would have to store each items permission on the pseudo groups.
Still seems simpler to just check their log in status instead of
creating another system requiring extra db space to do the same thing.

>From a logistics view, the group box is a multiple select box. You can
assign more than one group to an item. If the pseudo groups were
included, this could cause problems (user picks 'everyone' and another
group to view). I think the radio button solution still works best in
this situation.


> See above. I don't think we need a second table unless there are item 
> specific permissions just as fatcat doesn't have categories for 
> everything but has the psuedo-category of 'uncategorized'.

Look at the programming for how this is done. The faq module for example
pulls the data, finds out what is NOT in a category, and lists it as
uncategorized. This is, in my eyes, inefficient (not the fault of
Darren, more my fault for how I programmed the Fatcat). What I am having
to do in the new category module is actually have 0 as the id of the
category 'Uncategorized'. This way I can pull only those items from the
database. It creates more data but ultimately is more efficient.

For permissions however, it was far more efficient to just not have
these 0 or -1 ids.


> Hope so. I just wasn't sure you'd not missed something.

I hope I haven't either but (so far) I haven't run into an unsolvable
situation.

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

Re: [Phpwebsite-developers] Banning of users

[Shaun M. <sh...@ae...>]

On 23 Feb 2005, at 15:55, Matthew McNaney wrote:

>> For instance, you might want to make some blog entries readable
>> for guests and some for registered users only.
>
> Entries readable by anybody would be marked as "Anyone". Entries
> readable for registered users are marked as "Registered only". What you
> are suggesting already works.


Not the same. What works currently is that you can set blog entries as 
being BOTH registered and guest so that registered users see their 
stuff AND also they get guest stuff.

I was hoping there would be a 'guest only' group so that I could put 
blocks on the page that only non-registered users could see so that I 
could put adverts on the page if they weren't registered and the 
adverts would disappear if they registered.

>
>>  Also if you had a level
>> of user above registered, how do you specify that they can read the
>> special articles for them only, without also opening them up to normal
>> registered users? eg. for paid content.
>
> You set the entry with the third permission option, then choose the
> group that is allowed to view it.
>

So the admin interface is ...

( ) Everybody
( ) Registered users
( ) Specified group of users
     [Pick group(s)]

??

That's better than I thought but still more complicated than it needs 
to be IMHO and I'd still like to see a 'Guest Only' level.



>>  I really think it should be
>> item based permissions not module level.
>
> It is.

OK, I misunderstood what you meant originally.


>
>> Couldn't it be at a more core level like the level fatcat is at with a
>> similar kind of interface so that you could pick a permission level
>> from predefined groups?
>
> Should work like that.
> 1) Make a group with viewing permissions for your module. Give them
> restricted viewing access (ie they can only view specific items)
> 2) put the people you want to be able to view something in that group
> 3) make the entry
> 4) assign it to registered users with permission (the third option)
> 5) pick the group you want to view the entry.
>
> The above group would be able to view 1) entries set to anyone, 2)
> entries set to registered users, and 3) the entry you designated as
> readable by ONLY them. Anyone NOT in this group would not be able to 
> see
> the entry.
>
>>  That was my reasoning behind the dropdown with
>> a list of groups on any module's edit interface or even on say a block
>> in layout mode.
>
> The CVS version of blog 1.x has this coded. I haven't put it in block
> yet. I was going to post some screen shots but 1.x is busted right now
> :(
>
> As for the module developer having to keep track of permissions, they
> only have to keep track of viewing rights. Even then, checking is
> simple.
>
> // access_code is 0,1,2
> // 0 = everyone , 1 = registered only, 2 = certain registered users
>
> switch ($entry->access_code){
>
> case 1:
> if (!Current_User::isRegistered())
> 	return;
> break;
>
> case 2:
> if (!Current_User::authorized('blog', 'view', $entry_id))
> 	return;
> break;
> }
>
> Layout::add($entry->get());
> --------------------------------------------------------------------
> If I made the permission system handle viewing permissions, I would 
> have
> to:
>
> 1) create a default anonymous user
> I was going to do this. But why? We know who this is. It's a user that
> isn't logged in.
>
> 2) create a default registered user
> Again, why? We know who this it as well. It is someone that it logged
> in.
>

OK, I never thought they'd be actual users or groups, more a psuedo 
group that appears in the interface just as if it was an actual user 
group.


> 3) store view information on every item
> We can't give the default anonymous or registered user unrestricted 
> view
> permissions.
>
> An unrestricted group or user is permitted to edit, delete, etc. any
> item in the module. They are still confined to the permissions given to
> them however (just like the current system).
>
> A restricted group or user has permissions assigned to them as well, 
> but
> they can ONLY use them on items assigned by an unrestricted user.
>
> So, we do not want to give a group unrestricted view permissions. They
> would be able to view every item in the module. So we have to give them
> restricted view permissions so they could only view specific items.
>
> Herein lies the problem. Since they are restricted, they can only 
> access
> items assigned to them. Thus, we would have to assign view permissions
> to every group and user we wanted to see an item. This is bloated and
> unnecessary in my opinion. Permissions work best when exclusive not
> inclusive.
>
> Yes, I know it works in unix, but this ain't unix.

I didn't understand the above at all but I'll proceed nonetheless ;-)

I was guessing it would work on the basis of the permission system 
looking up the default permissions for the module as set in the user 
control panel interface for the group the user was in and using those 
if it found no specific settings for the item. That's why I was 
simplifying guests and registered users as a pseudo group so that 
setting permissions for guests was as simple as it is now for groups. 
That way, you could dissallow viewing all content in a module from 
guests.

So, from a module developers point of view, all they do is ask the 
permission system if it's authorised content, the permission system 
checks if there is specific item info, failing that goes with the group 
permissions.

 From an admins point of view they see a box with a list of groups, some 
of which are real, some are predefined psuedo-groups. If they choose a 
group an item specific entry is set, if not the system picks the module 
defaults.

>
> 4) create a special table duplicating the system above
> So every item would have a duplicate table that just stored the viewing
> access codes. Why? Sure it may be more convenient but all I ask is to
> store the information WITH the item table itself. I don't think it is
> too much to ask. Each item table already has a sequence table and (if
> they are using it) a version table. I think another is too much for too
> little benefit.
>

See above. I don't think we need a second table unless there are item 
specific permissions just as fatcat doesn't have categories for 
everything but has the psuedo-category of 'uncategorized'.


> This is a long winded explanation but let me just conclude by saying:
> you should be able to control group and user permissions however you
> wish in 1.x. Although users does 99% of the permission work, a module
> developer can add the other 1% to get viewing functionality as well.
>

Hope so. I just wasn't sure you'd not missed something.


Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] Banning of users

[Matthew M. <ma...@tu...>]

> For instance, you might want to make some blog entries readable 
> for guests and some for registered users only.

Entries readable by anybody would be marked as "Anyone". Entries
readable for registered users are marked as "Registered only". What you
are suggesting already works.

>  Also if you had a level 
> of user above registered, how do you specify that they can read the 
> special articles for them only, without also opening them up to normal 
> registered users? eg. for paid content.

You set the entry with the third permission option, then choose the
group that is allowed to view it.

>  I really think it should be 
> item based permissions not module level.

It is.

> Couldn't it be at a more core level like the level fatcat is at with a 
> similar kind of interface so that you could pick a permission level 
> from predefined groups?

Should work like that.
1) Make a group with viewing permissions for your module. Give them
restricted viewing access (ie they can only view specific items)
2) put the people you want to be able to view something in that group
3) make the entry
4) assign it to registered users with permission (the third option)
5) pick the group you want to view the entry.

The above group would be able to view 1) entries set to anyone, 2)
entries set to registered users, and 3) the entry you designated as
readable by ONLY them. Anyone NOT in this group would not be able to see
the entry.

>  That was my reasoning behind the dropdown with 
> a list of groups on any module's edit interface or even on say a block 
> in layout mode.

The CVS version of blog 1.x has this coded. I haven't put it in block
yet. I was going to post some screen shots but 1.x is busted right now
:(

As for the module developer having to keep track of permissions, they
only have to keep track of viewing rights. Even then, checking is
simple.

// access_code is 0,1,2
// 0 = everyone , 1 = registered only, 2 = certain registered users

switch ($entry->access_code){

case 1:
if (!Current_User::isRegistered())
	return;
break;

case 2:
if (!Current_User::authorized('blog', 'view', $entry_id))
	return;
break;
}

Layout::add($entry->get());
--------------------------------------------------------------------
If I made the permission system handle viewing permissions, I would have
to:

1) create a default anonymous user
I was going to do this. But why? We know who this is. It's a user that
isn't logged in.

2) create a default registered user
Again, why? We know who this it as well. It is someone that it logged
in.

3) store view information on every item
We can't give the default anonymous or registered user unrestricted view
permissions.

An unrestricted group or user is permitted to edit, delete, etc. any
item in the module. They are still confined to the permissions given to
them however (just like the current system).

A restricted group or user has permissions assigned to them as well, but
they can ONLY use them on items assigned by an unrestricted user.

So, we do not want to give a group unrestricted view permissions. They
would be able to view every item in the module. So we have to give them
restricted view permissions so they could only view specific items.

Herein lies the problem. Since they are restricted, they can only access
items assigned to them. Thus, we would have to assign view permissions
to every group and user we wanted to see an item. This is bloated and
unnecessary in my opinion. Permissions work best when exclusive not
inclusive.

Yes, I know it works in unix, but this ain't unix.

4) create a special table duplicating the system above
So every item would have a duplicate table that just stored the viewing
access codes. Why? Sure it may be more convenient but all I ask is to
store the information WITH the item table itself. I don't think it is
too much to ask. Each item table already has a sequence table and (if
they are using it) a version table. I think another is too much for too
little benefit.

This is a long winded explanation but let me just conclude by saying:
you should be able to control group and user permissions however you
wish in 1.x. Although users does 99% of the permission work, a module
developer can add the other 1% to get viewing functionality as well.


-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

Re: [Phpwebsite-developers] Banning of users

[Shaun M. <sh...@ae...>]

On 23 Feb 2005, at 13:34, Matthew McNaney wrote:
>
> This is in place but you have to hand-hold with the permission system.
> For the example the blog entries have int column for authorization.
> 0 - Anyone can see this blog
> 1 - Registered users can see this blog
> 2 - Registered groups who have view permission for this item can see 
> it.
>

That would mostly work but I'm not that keen on this method as it puts 
the emphasis on the module developer to implement permissions in each 
module and in the case of the example isn't fine grained enough for 
some. For instance, you might want to make some blog entries readable 
for guests and some for registered users only. Also if you had a level 
of user above registered, how do you specify that they can read the 
special articles for them only, without also opening them up to normal 
registered users? eg. for paid content. I really think it should be 
item based permissions not module level.

Couldn't it be at a more core level like the level fatcat is at with a 
similar kind of interface so that you could pick a permission level 
from predefined groups? That was my reasoning behind the dropdown with 
a list of groups on any module's edit interface or even on say a block 
in layout mode.


Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] the mod_user_uservars table

[Shaun M. <sh...@ae...>]

On 23 Feb 2005, at 13:36, Matthew McNaney wrote:

> It was a bad idea. No one uses it. Expect it to wither away by 1.x.
>

I suspect that's because not many people know it's there!

Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] Banning of users

[Matthew M. <ma...@tu...>]

> 'Guests'

When you haven't logged in yet, you are a guest.

> 'Registered'

When you get an account, you are registered

> 'Admins'

No singular designation, though you could create an admin group and put
people into it.

> 'Deities'

Will work just like 0.x. A deity is a user, not a group. It is a special
all powerful designation.

> 'Banned'

This is not in 1.x although I don't have any arguments against putting
it in place.

> And hopefully some easy method of allowing viewing content to be set to  
> a group permission.

This is in place but you have to hand-hold with the permission system.
For the example the blog entries have int column for authorization.
0 - Anyone can see this blog
1 - Registered users can see this blog
2 - Registered groups who have view permission for this item can see it.

Thanks for the input about this.

-- 
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

Re: [Phpwebsite-developers] the mod_user_uservars table

[Matthew M. <ma...@tu...>]

On Wed, 2005-02-23 at 09:02 +0100, Ren=C3=A9 C. Kiesler wrote:
> Hi!
> =20
> I've stumbled across that table and wonder about its content. It seems =
to
> contain some kind of user preferences.

It's original function was to retain user information on the server
instead of in a cookie. The column could contain any type of data,
therefore an array or object would get serialized.

It was a bad idea. No one uses it. Expect it to wither away by 1.x.

--=20
Matthew McNaney
Electronic Student Services
Appalachian State University
http://phpwebsite.appstate.edu

Re: [Phpwebsite-developers] the mod_user_uservars table

[Shaun M. <sh...@ae...>]

On 23 Feb 2005, at 08:02, Ren=E9 C. Kiesler wrote:
>
>
> Also, why is the rememberme-setting encoded that strangely? for =
example
> "a:1:{s:9:"mod_users";a:1:{s:10:"rememberme";s:2:"-1";}}". Wouldn't a
> "rememberme=3D-1" be enough? And maybe a second variable for
> "current_language"?
>
>

Any module can add it's own user specific variables to that table. The=20=

data is serialized - go look at serialize() on php.net. If you just=20
added extra columns to the table it wouldn't be general purpose or=20
extendable.

You set and get them using setUserVar() and getUserVar()

This is all in the user module developer docs.=20
/mod/users/docs/devdoc.txt

Shaun
aegis design - http://www.aegisdesign.co.uk

[Phpwebsite-developers] the mod_user_uservars table

[<re...@ki...>]

Hi!
=20
I've stumbled across that table and wonder about its content. It seems =
to
contain some kind of user preferences.
=20
Some variables are easy to guess.
=20
"theme" seems to contain the current theme, "forgotDateTime" the time, =
when
the user requested a new password, MOD_ entries contain permissions, =
etc.
=20

But there are variables I can't make sense of. Maybe someone can help me
here? I'm thinking about stuff like
=20
- loginToList
- desc_status
- image_status

=20
Also, why is the rememberme-setting encoded that strangely? for example
"a:1:{s:9:"mod_users";a:1:{s:10:"rememberme";s:2:"-1";}}". Wouldn't a
"rememberme=3D-1" be enough? And maybe a second variable for
"current_language"?


Thank you // Ren=E9!

Re: [Phpwebsite-developers] Banning of users

[Shaun M. <sh...@ae...>]

On 22 Feb 2005, at 18:03, Eloi George wrote:

> In June 2003, Richard Sumilang suggested changing the Admin switch to  
> an "Activate/Disable account" switch.  All the active  developers at  
> the time supported it and the core team agreed to code it.  However,  
> with all the extra projects they had to work on and the fact that  
> noone ever submitted an RFE, we all just kind of forgot about it.
> The thread where this happened is at  
> https://sourceforge.net/mailarchive/forum.php? 
> thread_id=2898205&forum_id=34704
>
> To rectify the situation, I've just submitted an RFE.  
> https://sourceforge.net/tracker/index.php? 
> func=detail&aid=1146448&group_id=15539&atid=365539
> I urge you all to put your "+1" on it again as an indication of our  
> desire for this change.

So, the current permission system seems to be that the permissions  
aren't used unless you're an admin? That does indeed seem superfluous  
although being able to switch on/off all the permissions for a user  
might be handy. So, in theory +1.

Couldn't we just sidestep this by having a group of users defined with  
no permissions and moving the user to that group if you want to ban  
them? Simplify the whole interface by just having a group pulldown to  
assign them to a group.

I hope, for 1.0, we have some default user groups sorted with  
appropriate default permissions. How about....

'Guests'
'Registered'
'Admins'
'Deities'
'Banned'

And hopefully some easy method of allowing viewing content to be set to  
a group permission.


Shaun
aegis design - http://www.aegisdesign.co.uk

Re: [Phpwebsite-developers] Banning of users

[Kenneth P. <ken...@gm...>]

+1 - indeed a very good and useful feature!

Kenneth


On Tue, 22 Feb 2005 14:03:38 -0400, Eloi George <el...@re...> wrote:
> In June 2003, Richard Sumilang suggested changing the Admin switch to an
> "Activate/Disable account" switch.  All the active  developers at the
> time supported it and the core team agreed to code it.  However, with
> all the extra projects they had to work on and the fact that noone ever
> submitted an RFE, we all just kind of forgot about it.
> 
> The thread where this happened is at
> https://sourceforge.net/mailarchive/forum.php?thread_id=2898205&forum_id=34704
> 
> To rectify the situation, I've just submitted an RFE.
> https://sourceforge.net/tracker/index.php?func=detail&aid=1146448&group_id=15539&atid=365539
> I urge you all to put your "+1" on it again as an indication of our
> desire for this change.
> 
> -Eloi-
> 
> 
> 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.
> >
> >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.
> >>
> >>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='$user_id'") ==
> >>'DENIED')) {
> >>
> >>Will spit out the message:
> >>Unable to email change form.
> >>Please contact the systems administrator.
> >>
> >>HTH
> >>
> >>Wendall
> >>
> >>On Fri, 2005-02-18 at 02:13 -0800, Greg Tassone wrote:
> >>
> >>
> >>>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 when
> >>>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/break
> >>>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 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 simple
> >>>to add and would probably disable most/all functionality within the
> >>>site.
> >>>
> >>>However, do you have any reasons for/against?  Any better ways?  Is this
> >>>already done so that I don't have to worry about it? ;-)
> >>>
> >>>Thanks in advance!
> >>>
> >>>Greg T.
> >>>
> >>>
> >>>
> >>
> >>-------------------------------------------------------
> >>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
> >>
> >>
> *______________________*
> 
> 
> -------------------------------------------------------
> 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
> 
> 


-- 
  Kenneth

Re: [Phpwebsite-developers] Banning of users

[Eloi G. <el...@re...>]

In June 2003, Richard Sumilang suggested changing the Admin switch to an 
"Activate/Disable account" switch.  All the active  developers at the 
time supported it and the core team agreed to code it.  However, with 
all the extra projects they had to work on and the fact that noone ever 
submitted an RFE, we all just kind of forgot about it. 

The thread where this happened is at 
https://sourceforge.net/mailarchive/forum.php?thread_id=2898205&forum_id=34704

To rectify the situation, I've just submitted an RFE. 
https://sourceforge.net/tracker/index.php?func=detail&aid=1146448&group_id=15539&atid=365539
I urge you all to put your "+1" on it again as an indication of our 
desire for this change.

-Eloi-


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.
>
>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.
>>
>>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='$user_id'") ==
>>'DENIED')) {
>>
>>Will spit out the message:
>>Unable to email change form. 
>>Please contact the systems administrator.
>>
>>HTH
>>
>>Wendall
>>
>>On Fri, 2005-02-18 at 02:13 -0800, Greg Tassone wrote:
>>    
>>
>>>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 when
>>>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/break
>>>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 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 simple
>>>to add and would probably disable most/all functionality within the
>>>site.
>>>
>>>However, do you have any reasons for/against?  Any better ways?  Is this
>>>already done so that I don't have to worry about it? ;-)
>>>
>>>Thanks in advance!
>>>
>>>Greg T.
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>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
>>    
>>
*______________________*

Re: [Phpwebsite-developers] default template in pagemaster

[Matthew M. <ma...@tu...>]

Yes. You could create several page templates and set different styles.

For example

<div id="pagestyle1">
...content here...
</div>

Make a box
<div class="box">
.. content here ...
</div>

Then in your theme's style sheet

#pagestyle1 div.box {
 background-color : red;
}

#pagestyle2 div.box {
  background-color : yellow;
}

Just experiment.

On Sat, 2005-02-19 at 05:48 -0500, yawstick wrote:
> When you create a new page via pagemaster, in the first form there is a
> place to set template for the page. I have found this template and there is
> not much in it. Would it be possible to add another template that would set
> the boxstyle used for that page to something other than what is used for the
> rest of the pagemaster pages.
> 
> 
> Thanks
> 
> Paul
> 
> 
> 
> -------------------------------------------------------
> 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

Re: [Phpwebsite-developers] default template in pagemaster

[Jim W. <spi...@us...>]

> -----Original Message-----
> From: "yawstick"
> Sent: Saturday, 19. Feb 2005 5:48 -0500
> To: <php...@li...>
> Subject: [Phpwebsite-developers] default template in pagemaster
> 
> When you create a new page via pagemaster, in the first form there is
a
> place to set template for the page. I have found this template and
there is
> not much in it. Would it be possible to add another template that
would set
> the boxstyle used for that page to something other than what is used
for the
> rest of the pagemaster pages.
> 

Hi Paul,

There are page templates and boxstyle templates, but you can copy any
tpl file 
to another file in the same directory and it will show up as a choice on
that 
first form (listed with whatever name you gave the file).

Best regards,

Jim Wilson

[Phpwebsite-developers] default template in pagemaster

[yawstick <yaw...@ch...>]

When you create a new page via pagemaster, in the first form there is a
place to set template for the page. I have found this template and there is
not much in it. Would it be possible to add another template that would set
the boxstyle used for that page to something other than what is used for the
rest of the pagemaster pages.


Thanks

Paul

[Phpwebsite-developers] [0.8.x] Calendar swallowing dates

[Ulf H. <U1...@ul...>]

Hi,

I am running one of my sites still based on V 0.8.something. I know it's 
a shame but the code is so heavily customized that I did not dare to 
upgrade yet. I just noticed a calendar bug: Some dates seem to get 
swallowed, my guess is that if the 1st of a month is a sunday, it won't 
be displayed. If you are interested, you can check this out at
http://www.werow.com/mod.php?mod=calendar&op=month_view&date=20050501
--the 1st of may is gone.

I wonder if any of you guys remembers whether that bug ever got fixed.
If you could give me a hint where I could find a snipped of code that 
fixes it I'd really apprechiate it.

Grettings from Munich

Ulf

Re: [Phpwebsite-developers] Banning of users

[Greg T. <gt-...@ta...>]

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

Re: [Phpwebsite-developers] Banning of users

[Wendall C. <wen...@to...>]

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='$user_id'") ==
'DENIED')) {

Will spit out the message:
Unable to email change form. 
Please contact the systems administrator.

HTH

Wendall

On Fri, 2005-02-18 at 02:13 -0800, Greg Tassone wrote:
> 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 when
> 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/break
> 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 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 simple
> to add and would probably disable most/all functionality within the
> site.
> 
> However, do you have any reasons for/against?  Any better ways?  Is this
> already done so that I don't have to worry about it? ;-)
> 
> Thanks in advance!
> 
> Greg T.
> 

[Phpwebsite-developers] Banning of users

[Greg T. <gt-...@ta...>]

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 when
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/break
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 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 simple
to add and would probably disable most/all functionality within the
site.

However, do you have any reasons for/against?  Any better ways?  Is this
already done so that I don't have to worry about it? ;-)

Thanks in advance!

Greg T.

Re: [Phpwebsite-developers] Answer to the question

[Kenneth P. <ken...@gm...>]

On Tue, 15 Feb 2005 15:40:25 -0500, Matthew McNaney
<ma...@tu...> wrote:
> ...
> Mere words can not express our situation, but now there is a web site
> that says it all.
> 
> http://www.itc.appstate.edu/
> 
> This site and its design encompasses what we are up against.
> 
> Enjoy.
> 

Say no more... what a mess!

Kenneth