Also, I wouldn't write the code to echo an error if they don't have permission... Instead, I would write the code to just not include what they don't have access to... but that's just me.
multiple user levels
but I was confused about this:
if(!isset($COOKIE['User'] or $COOKIE['admin']))
can I use that "or" so I can allow multiple levels?
Thanks
Sure, but you still have to have a way of being able to identify whether the user is a user or admin, and load that into the cookie array. That is what you need to find a working solution to.
Hi p0pb0b,
I think he meant it as a session variable, not a cookie variable. a cookie would be too easy to spoof.
fwiw, I got turned on to phplib early in my learning php-- and it really saved me from having to reinvent the wheel. It has sessions, database abstraction, authentication levels, templates.... well worth the minimal learning curve.
It would no doubt serve you well on your lyrics site 
[edit]Good grief, I go get a glass of water and you guys left me in the dust... this was a response to the 1st response.[/edit]
something like this:
$db = mysql_connect("localhost", "user", "password");
mysql_select_db("user",$db);
$sql = 'SELECT * FROM user';
$result = mysql_query($sql);
$data = mysql_fetch_array( $result )
if(mysql_num_rows($result) == 1)
{
if($data['level'] == admin)
{
setcookie("admin", TRUE, time()+(3600 * 24));
}
if($data['level'] == editor)
{
setcookie("2", TRUE, time()+(3600 * 24));
}
if($data['level'] == user)
{
setcookie("3", TRUE, time()+(3600 * 24));
}
else
{
//redirect to normal non-login page
}
Im a newbie the ifs got me confused.. maybe u can help me out, thanks
whats phplib
PHPLib is a library of objects that take care of sessions, authentication (logging in with different permission levels), templates, etc.
It's useful on several different levels-- no more writing mysql_some_function_or_other; instead you would write something like $db->query("select...."); to iterate through a result set, you would while($db->next_record()) { etc.
logging in is accomplished simply by calling one function: if the user is not logged in, it halts the script and includes a login form.
Then you can selectively display content based on the user's auth level.
...and so on!
I didn't even think of that PhpLib would be the way to go... I guess I am all gung-ho to reinvent the wheel since I just got done writing a complete admin function for a calendar script I wrote from scratch 
Hmmm.. but phplib... is it an addon for php or what is it? So some web hosts might not have it?
It's a collection of scripts. You have to upload it to your site.
ooo... so then I could just include those pages and then call those functions?
I'm gonna have to look at phplib.
Another option which I prefer to security levels is more like the way novel does security with their servers. A very very basic implementation would be the following:
Have a "UserRights" table which contains UserName, RightName. Primary key both fields together.
Have a function HasRight($RightName). This function does a SQL query to find out if the user has the particular right to access that particular spot on a page. As someone earlier mentioned, rather than displaying an error, just excluding the part that they don't have access to is much more effective. The reason for this is that you can use the same system (ie menu, options etc) for any user, and only the stuff they have access will show up.
An implementation would look a little like:
<?php
include("rights.inc");
if (HasRight("search"))
{
// do search stuff
}
if (HasRight("changepassword"))
{
// do password changing stuff
}
if (HasRight("hangoutwashing"))
{
// HEY!
}
?>From what the person who mentioned phplib said, this sounds like quite a similar type of thing. If you are looking for inspiration for how to write something like this, take a look at how Novell does this stuff with the network servers. The Novell stuff is very well thought out. You could also look at windows, but that's not done very well and probably not a good role model. The way linux is done is very good, but the structure is not really appropriate for doing security on a web page.
Summary, I don't think security levels is really a good way to go. It's very restrictive in that flexibility is pretty much non-existent. If requirements change or the project grows, you will have severe difficulties. Using Rights/Permissions/Privileges will give you signigicant flexibility for growing and adapting etc. For me, this has proved to be very successful.
I haven't had a change to look at phplib, but it sounds very promising.
hmm, there's a number of things. I do them automatically now, so it's just a matter of thinking of them. I'll post this to the main board as well.
This looks like it's going to be big, so here's a summary. I'll start off by giving an example on where security levels won't be sufficient and why. I'll then move on to alternatives. This is an expansion and contination of my previous post.
outline:
- example
- analysis
- template users
- groups
I remember HDM (Hard Disk Menu... that really old dos menu system) had security levels in it. The trouble I found with it was that it was well suited to small numbers of users and a small number of levels of users. It did support 99 levels, but managing who had superiority over who became a huge issue. This way of thinking implies a linear way of thinking. Ie peolpe at the bottom only want to do one thing (... no comment ) and gradually as ranks get higher, responsibilities are slowly added up.
The reason I dislike this way of thinking is because it doesn't cater for different sets of users. Example:
Back when I was at school, they had a Novell network (ver 3.11)
There were the following role (actually more, but this is enough for the example):
Teachers (Email,Access to staff pool area, marks, wp apps etc)
Students (Email... that was about it back then)
StudentAdmin (controls student access)
Supervisor (think administrator)
Accounting (financial info)
Backups (had access to read everything)
It's probably obvious to say that Teachers and Students should not have supervisor priviledges over the other users. In security levels, this could be equated to the person right at the top with most access. However, the person who is in the supervisor role, does not want to have to be there all the time since there are quite a few other networks that he was administering. So he would delegate responsibility to other users. However different responsibilities needed to be delegated to different people so that no one person had complete control over the whole network. Thus the following roles were created:
StudentAdmin: This was the science teacher at the time. He could create * delete student users, modify their passwords, change their names etc
Accounting: Had access to sensitive information about the school. There is no way students should have access to this information. In fact even most teachers wouldn't see it.
Backups: Could read everything on the network, but could only write to the backup medium. If there was a call to restore something, I believe the supervisor was called in (from 60km away).
Students: Initally could only check email, but later could do some other things as well.
Teachers: Had their own private staff pool as well as their own private home drive (students had a shared one). Staff had no need for the student programs, and thus to keep things simple for the teachers (who mostly were not particularly computer literate) did not have access to the stuff the students had.
If should be becomming pretty apparent why security levels wouldn't work in this situation. The different people have different responsibilities. Some of the roles over lap and some work in parrallel. This just can't be feasilbly implemented with security levels.
I have a policy that members can not login without a password being set. As you can probably imagine, this is easy to test for, but it means you can use this to create dummy accounts as templates. In windows these are called template users, in Novell it's "inherit rights from". I apply it in a way that allows me to make a user inherit rights from more than one user. The structure of the table means that a user will only have one copy of a right, even if it has been granted more than once.
Asigning rights to users works well to begin with, but then imagine you have a whole heap of users. Let's say anything up from a hunder or so. Assignning rights to the users individually is going to become a pain in the neck. Using template users as I mentioned above will reduce the problem, but by itself is not going to help a lot as the company (and thus user roles) change. This is where groups (think roles) come in. Groups allow the administrator to give someone rights by simply putting a user in a group. For granting rights, this isn't going to make a lot of difference, however for removeing rights the difference is huge. If a user stops doing something (let's say accounting), they can simply be removed from the accounting group and all the rights that are associated with that group will be removed. However if there is a right that was in that group, but was also in another group that user is in... the removal of the first group will not interfer with any other groups, meaning that they will still have that right.
Example: Staff member is also a student. They finish and pass all classes and are now just a teacher. Both of them have email access, but the teacher no longer has need for the student programs. The user is removed from the student group removing the student programs, but the email will remain since the user is also in the teacher group.
How does this look in the db:
User: pk(UserName), Password, FirstName, LastName
UserRight: pk(UserName, RightName)
UserGroup: pk(UserName, GroupName)
GroupRight: pk(GroupName, RightName)
I've done this so all columb names that are the same line up.
A setup like this will provide the ability to use:
- Temlpate users
- Groups
- Individual Rights
- Group rights
TIP: don't hard code abilities to groups. Hard code to rights. IE:
If (HasRight("Search"))
{
// do search stuff
}
Let HasRight($RightName) do ALL the work of sussing out the groups. If can sub-contract out the work to other smaller functions if nessary, but what ever you do, DO NOT DO SOMETHING LIKE THIS:
If (HasRight("Search") or HasGroup("Teacher") or HasUser("bob234"))
{
// do search stuff
}
That would lead to disaster. Insteadlet HasRight($RightName) find were the user has the right. Assign rights to the actions and then assign those rights to group roles. And then the group roles to Users. You could even skip out the:
UserRight: pk(UserName, RightName)
and let everything happen through groups.
Using groups is a little more resource intensive than just assigning rights, but the difference it makes to administration is immense.
Things to consider:
- Who can assign what rights? I often want some people to be able to grant certain rights to other users, while a different user might be able to grant different rights to same or different users. This consept can easily be implemented by adding rights which a user may grant to a dropdown menu. this list could be considerable or really small and it would still work well.
- Who can be administered by who. This could be done by adding a table:
GroupAdmin: pk(GroupName, GroupNameAdmin)
This way groups can administer groups. Note that the GroupNameAdmin is referencing GroupName on other tables.
To sum up:
At the end of the day, creating a system like this for something really simple is probably over kill. You can always begin small with something like security levels and then if you need to assign rights later on, you could do an update query to convert users security levels to specific rights. Personally, I find right/permissions/priviledges a mich better way to work because there is so little effort to add new areas to the site. All that's needed it to create the new area, assign it a rightName and give some users that right. Security levels become a "which levels should have this access?, who has that level?, do I need a new level?..."
As I've mentioned before, Novell does this stuff really well. If you can take a look at it, it would be very benificial. I learn't on version 3.11 using a DOS client and that was very well thought out.
I need to go and do some other things now. I think the best thing from here is to look where you are unsure and I'm happy to answer questions. If there's enough interest, I might compile and organise this post, the previous one and any stuff the follows to make an article. Is there interest for that?
PS: If you really wanted, you could create a table which along the lines of:
Rights: pk(RightName), Description
This would be handy if you want to use dropdown menus to assign rights. Tables like this could be done for groups etc as well.
Soon after my last post, I thought of a whole heap more that is relevant. Unfortunatley most of those thoughts seem to be hiding from me, but maybe if I start out with some of the stuff, it might flow.
Another possibility which Novel implements is equivilances. I'm bringing this up as a "probably don't do it, but be aware of it" type scenario. It basically works by the user having all the rights another specified user/group has plus any rights which are specifically granted to it by means I have discussed in the previous posts.
I don't know if the latest versions of Novell Netware still have this feature as there are only two real advantages of the feature (that I'm aware of).
1) Having a large number of users with the same rights that might change (frequently enough to warrant using this feature)
2) Hacking. This is an excellent tool for hacking because they just need to grant equivilances to supervisor and the chances are that until they do something stupid, no-one will notice.
The first of those two benifits can easily be achieved by using groups. IE create a group which all those users are members of and then modify the group. This would be cleaner and if leaves a paper (virtual) trail that means hackers would be more visible.
The second... need I say more?
Sadly, the rest of what I was going to say still has not come out of hiding.
The point of this post was to say that "here is another option, but it's not worth it". It doesn't add anything which can't already be done with what was mentioned in the other posts, but it does add security issues.
I feel like this post is a bit of a let down. Hope it helps.