Limiting page access

[Sulman]

Hi all,

 

I'm after some ideas about how best to limit my users to certain pages.

 

There are a lot of pages and some pages I want certain users to be able to access and some I don't.

 

How is it best to manage this? Will I need to have a table with every single page of my site listed along with who is authorised to view them  (be it individual users or groups) and check this on every page?

 

That seems like a really inefficient way to do it.

 

Any other ways?

Thanks!

[uniflare]

i would user user groups and make each protected page have a specific user - group requirement...

[redarrow]

Add permission to the users login database field......

 

when the user login set a session for permission

 

1 allowed

2 not allowed

 

if($_SESSION['permission']==2){

 

redirect user

 

)else{

 

i can see everythink

 

}

[discomatt]

I would NOT store permission values in a session. It's not uncommon for a session to be stored in a cookie... a value the end user has complete access to read and modify.

 

Store user/pass in the session, and grab the permission from the database based on the user/pass combo on every page view.

[redarrow]

ok then use database field permission then use a select statement..........

 

dont use session's then as told sorry

 

SELECT * FROM WHAT_EVER WHERE PERMISION=1 AND

USERNAME='".$_SESSION['USERNAME']."' AND

PASSWORD='".$_SESSION['PASSWORD']."'";

[deadonarrival]

i would user user groups and make each protected page have a specific user - group requirement...

 

I'd agree with this

 

Basically set up as many user groups as you need.

 

Eg

1- normal users

2- mods

3- admins

 

Then you can do one of two things. If you need basic "can/cant see this page" functionality, just use

<?php
//check userlevel
if($userlevel_from_database >= 2) //change 2 to whichever user level can see the page.
{
   //They're the required user level or higher
   #Display page
}
else
{
  //They're not a high enough user level!
  #Redirect or display error message
}
?>

 

Alternatively you can use another table called something like permissions, to allow the user to do certain tasks or not.

 

I can't really explain this one too well. If you can/have one, look at your mysql database user table, it shows it nicely

 

Otherwise I'll try to explain

Basically you have the userlevel, followed by fields for what the user can/cant do. Eg I have "view static pages", "view blog", "post blog", "comment blog", "view forum", "post in forum".... and so on for anything I have to choose.

 

I include anything I can possibly think of, just because it allows for most expansion in the future, and is useful sometimes. For example I once thought I'd never want to stop people viewing blogs, but when we found quite a serious bug I could very quickly limit access to admins with "UPDATE `permissions` SET `viewblog`='0' WHERE `id`<'5'";

 

I could've done it in the actual page, but that leads to the possibility of breaking the page, and the permissions thing can be updated from within the site, the admin doesn't have to go into the source code to do it. (IE someone less computer literate than I could manage it)

 

Anyway, back to the example.

Just use a simple if statement and query to check if the user has permission to view that page.

eg

<?php
#Get the userlevel from the database
#Grab the permissions list

if($perm->viewblog != 1)
{
   #Error message
}
else
{
  #Rest of blog code
}
?>

 

And once you have the permissions list (in the above example I would've used

$perm = mysql_fetch_object(mysql_query("SELECT * FROM `permissions` WHERE `id`='{$user->userlevel}'"));

This is just because I prefer the object syntax to the array syntax... feel free to use mysql_fetch_array() or any other method you choose.

[uniflare]

you can use user groups and permissions together  eg:

 

table user_groups

 

  id      name      permissions

 

table users

  id      name      pass      group      permissions

 

 

 

hope this helps,

[deadonarrival]

A bit pointless to have seperate permissions for users and groups IMO. I can think of a few odd occasions (eg if you might want to be able to take some privelidges from users) but that only confuses matters.

[discomatt]

Since when is flexibility a bad thing?

[deadonarrival]

Flexibility is never really a bad thing, and being able to set user permissions can be good at times... but what if you have several thousand users? Changing one permission for every account is a lot of sql queries - and if you need to do certain accounts only is VERY time consuming.

 

That's the entire idea around user groups - you give everyone a group, and decide what the group can and can't do.

 

It can be quite flexible. I only mentioned admin/mod/user permissions, but you could go into changing user group based on number of posts, or add donators. I use it as a "ban" technique. Instead of kicking users off my site (and more often than not losing the user) I give short bans, where the user is given limited permissions for a few days. A lot more effective.

 

Like I said, if you will only have a few accounts with different permissions, it's not too much hassle, but usergroups can be as flexible, without the overhead.

 

example.

You have 10 users, 3 have one permission set, 5 have another and 2 have very unique permission sets.

There are 10 permissions - or things the users can and can't do.

 

In this scenario (even with very few users) then with 4 user groups (one for the 3, one for the 5 and one each for the other two) you only need 40 fields in your database. If you need to change one person to have unique permissions, you can make another group with 10 fields (and 1 to change their group), but if you need to change the 5 people's permissions, it needs only change one set (10 changes).

 

Say you had the same 10 users, but each user had their own permissions set, to change one you would change 10 fields instead of 11 (only this time you're changing them instead of adding). A tiny bit easier...

 

BUT if you wanted to change the permissions of the 5, you'd have to manually input their names, meaning you'd have to enter 5 names AND THEN update 10 permissions each... 50 changes

 

Even with only 10 users it makes sense (even if my explaination may not). Now what if you had 1million users? Do you really want to have to go all the way through the table to change 2 fields for 500,000 people (1million changes), or would you rather change it in one user group (two changes).

 

The same overhead to give one person their own permissions (plus one field change) for a saving of thousands.

[Sulman]

Thanks all for your suggestions.

 

I do currently have a permissions table but that simpy controls what navigation is seen. It does not deny access to users who type in to the addy bar (how dare they!).

 

I won't be storing any permissions data in cookies/session so that just leaves a db check on every page.

 

What I thought about doing was having the page name and allowed user id in a db, eg:

 

orders.php

 

Page NameAllowed_User

orders.php12345

delivery.php12346

 

Then first thing in each page get the page name and then check against the db and the user_id in the cookie (this way I can have a generic function for every page).

 

I suppose I have to put up with hitting the DB every page load?

 

Thanks again.

 

 

 

 

 

 

[deadonarrival]

Yes, you'll have to hit the db every time. Usually more than once. It's not that big of a load really. I'd suggest adding to the permissions table... you're querying it anyway to get the navigation so you're not adding much overhead.

[trq]

I would NOT store permission values in a session. It's not uncommon for a session to be stored in a cookie... a value the end user has complete access to read and modify.

 

Store user/pass in the session, and grab the permission from the database based on the user/pass combo on every page view.

 

Sessions are stored on the server (always) and cannot be accessed by the client. Storing a users permissions within sessions is an acceptable and my recommended approach.

[phpSensei]

Why don't you set passwords for the pages? Then those who should enter the page are those that know the password, but I am guessing those people must be really trusty, and you don't find that alot these days.

[Sulman]

Well users will have already logged in to the admin area so having them log in to other pages as well could be a bit extreme.

[Sulman]

Sessions are stored on the server (always) and cannot be accessed by the client. Storing a users permissions within sessions is an acceptable and my recommended approach.

 

That would mean I could have a large session object stored though(as there will be many pages with different permissions).

 

Do you think that would be an issue?

[trq]

The pages may have different permissions but your users shouldn't. I use a system similar to that of a *nix based OS.

 

Each record (or page) needs three different attributes. An owner, a group and permissions. eg;

 

thorpe foo 640

 

The permissions are broken into three numbers the first representing the owner, the second the group and the third other. The numbers themselves represent different levels. 0 = nothing, 1 = execute, 2 = write and 4 = read.

 

So, given the example above. If I was the user thorpe I would have permissions to write and read (2+4) said record. If I was the user bob and belonged to the group foo I would be able to read said record (4) and if I where anyone else I would not have access to the record at all (0).

 

This sounds like quite a complex system but once you get your head around it, it really is extremely flexible.

[trq]

Oh... and after all that. All you need store in a users session to create the above flexability is there username, and an array of groups they might belong to.