[Resolved] Authentification Advice Please

miles_rich

I have recently built an authentification system, I am now reaching a problem wih it and wondered if anyine has any views advice for me on how to fix the problem.

At the moment the authentification system protects a site, with two options you are either a registered user or an unregistered user. Registered users can view all the pages, but unregistered users can only view specific pages. I have done this by including a protection page at the top of each page, which checks to see if they are logged in or not. This works fine, but now i need to create it so that each user has his/her own settings, for either viewing a page or fonts, colors etc...

What is the best way to do this as i have over 200 pages in total, and i need some users to be able to see some pages, and others not to.

Do i create a database whith page rights???
or what? as this would create a database with over 200 fields? (which cant be good)

Any advice / help would be good. Thankyou

Shrike

You basically can't do anything for unregistered users in terms of personalisation because you don't know who they are. All you need to do is create a database table and store the known users preferences, then when they log in pull the data back and do what you have to do.

Take a look at the sessions page on php.net as a good place to start.

Bear in mind that all you have is an 'unknown' user and a 'known' user. If you need to set per-page settings for each user then the only option worth considering is a full-blown content management system, where each page and each user has a representation in a database.

If you do think this is required, then it is a considerable amount of work but in the end does give you alot of control over your users and website. One biggie to consider is that different users will require different navigation dependant on their permission settings.

hth

miles_rich

THankyou for the advice but woulding the database containing all that info be huge? isnt this bad??

Weedpacket

A properly designed database wouldn't have two hundred fields, one for every page. It would have a separate table, with four fields per record. First field is a unique identifier so that every single record is guaranteed to be unique. Second field is the user's ID, third field is the page's ID, and the fourth field is the personalisation setting.

There will also be a table for users, and a table for pages for those IDs to relate to.

This is known as database normalisation.

miles_rich

So would the settings field be a delimated string, and then the string explodes when i need it?

Also

There will also be a table for users, and a table for pages for those IDs to relate to.

So this would protect pages, but what about functions with in those pages, for example if a function called all the stats for a server up, and only admins should see them, then i wouldnt want to call that function for normal users. Would i put a wrapper around that function call, or actually in the function to check if i was logged in as admin??

Weedpacket

Well, you'd have one field per setting. You could also have settings (on a per-page basis) to describe what kinds of user are allowed to see it or not. Or if there are that many classes of user, a single integer, and store each allow/deny as a single bit in that integer (the same way that Unix file permissions work).

Shrike

Would you really need to set personalisation settings per-page? I would think they would be global settings like a 'favourites' panel, CSS style, breadcrumb trail etc. The point about having each page registered in the database would be that you could apply a permission to each page, to allow

if($userpermission == $pagepermission){
  echo $page;
}else{
  echo $errorpage;
}

To my mind having personalisation per-page is
a- very flexible
b- a bugger to manage
c- incredibly inefficient

😉

miles_rich

OK Good point thanks to everyone who helped.