Misc Links
Forum Archive
News Archive
File DB



Latest Forum Topics
wow 56 k modems are
Posted by Red Squirrel
on Oct 14 2013, 11:52:23 pm

I Need A Program
Posted by rovingcowboy
on Sep 23 2013, 5:37:59 pm

having trouble witn lan
Posted by rovingcowboy
on Sep 23 2013, 5:40:56 pm

new problem for me
Posted by rovingcowboy
on Sep 23 2013, 5:54:09 pm

RBC Royal Bank
Posted by Red Squirrel
on Aug 13 2013, 6:48:08 pm


Creating your own content management system with php
Better control of site content and access
By Red Squirrel

To keep things simple, we won't use a database, but in most cases you would want to use a database to store all this information. Our file I/O php article explains the implementation of file and mysql driven databases.

So here is a way to handle logins, and as well as manage who has access to what. Remember that $module holds the value of the page requested, and we have access to this variable even though we are in a different file, because it is included after.

1: In most cases this information would be in a database, but for the sake of this tutorial, everything is static variables to make it easier to follow, and to avoid the need to look in a database. These 2 variables hold the username and password for a user account, in this case "root" with a password of "password". We store the password in MD5 for extra security.

2: These variables would also be in a database in most cases, usually in the same entry as each user. These hold the various permissions for each page, for each user. Never use this method in a real-life situation as it could get nasty...

3: Now that the "database" is loaded, we now check to see what user is logged in, by fetching the cookies. The user cookie would hold the username, and the password cookie would hold the MD5 string for the password.

4: If the user clicked the logout button (leading to index.php?authact=logout) then we run this "if" statement.

4.1: First we clear the cookie by replacing it with a blank one that expires in the past (and will be deleted)

4.2: We clear $loggedin vars, which are used in #6 to determine what user is logged in

5: This if statement only get's executed if a user has hit the "login" button on the login form containing a textbox called "user" and textbox called "pass".

5.1: this nested if statement checks to see if the entered information matches with the "database" otherwise we go to 5.5 which is an error saying it's the wrong username/password.

5.2: We set the cookie so that the session is remembered for a year (the current time + 365*24*60*60 seconds)

5.3: We then assign the correct permission data to the $user var which can be used throughout the modules to decide if a user has permission to do something.

5.4: We set the $loggedin vars to the correct information

(now out of both if statements)

6: This is where the $loggedin vars come in handy, we check to see if they are valid.

6.1: If root is logged in, then we assign the root's information to the $user var

6.2: Otherwise we assign the guest info instead.

6.3: Then we check if the wanted module (remember the $module variable in index.php?) is accessable by that user. If it's not, we replace the $module var with "login" so that when index.php continues it's stuff, it will load the login module instead of the wanted module.

Lost yet? Good. Since we're pretty much done. The rest of the code involved such as the header and footer is not really new code if you read our beginner php guides so I won't explain any of it, and most of it is html anyway and varies depending on the site. In this example we kept the html low end to concentrate on the engine which is index.php and auth.php.

If you want to see a working version of this script you can view or download it. It will also give you an idea of the directory structure, and contains the same comments as the ones used in this tutorial.

Oh and another thing, there's a small mistake in that code that I meant to put there (ok ok, so I did not really mean to, but decided to leave it there). It's not really a mistake, but rather unnecessary code. The mistake is at comment 5.3 Notice how we give $user the info, but we do the same on comment 6.2! This won't break anything, but it's simply a line of code that is not needed, so it can be removed.

When programming scripts/engines that consists of many documents, silly mistakes like these are possible and can impact performance on a large scale. So it's always good to try and notice these things since they can be harder to find.

On the next page, we'll take a look at a script I use for security here at Iceteks, well the login part of it.

Next Page
27236 Hits Pages: [1] [2] [3] [4] 1 Comments

Latest comments (newest first)
Posted by Andy on October 10th 2004 (08:52)
LOL I was about to say. WOW this guest is smart. Why can't i find someone like that at my site. laugh.gif
View all comments
Post comment

Top Articles Latest Articles
- What are .bin files for? (669062 reads)
- Text searching in linux with grep (161180 reads)
- Big Brother and Ndisuio.sys (150471 reads)
- PSP User's Guide (139547 reads)
- SPFDisk (Special Fdisk) Partition Manager (117240 reads)
- How to Use MDADM Linux Raid (188 reads)
- What is Cloud Computing? (1225 reads)
- Dynamic Forum Signatures (version 2) (8769 reads)
- Successfully Hacking your iPhone or iTouch (18714 reads)
- Ultima Online Newbie Guide (35906 reads)
corner image

This site best viewed in a W3C standard browser at 800*600 or higher
Site design by Red Squirrel | Contact
© Copyright 2019 Ryan Auclair/IceTeks, All rights reserved