Create Logins for Clients Only to See There Pages

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
datahost
Forum Newbie
Posts: 1
Joined: Tue Oct 18, 2005 8:29 am

Create Logins for Clients Only to See There Pages

Post by datahost »

I have a series of editable forms and reports that I have created for clients to fill in, edit, save, print etc. in a web application based on PHP and MySQL.

I now want to allocate these to individual clients (about 15) and a secure login for them with the ability to be able to only see their forms and their reports and none of the other clients.

Suggestions as to how we could go about this conceptually or in detail would be appreciated or if any one knows of any existing software that would assist in achieving this.

Any recommended books, articles etc would also help.

Thank you as always

Regards,

:D
User avatar
jwalsh
Forum Contributor
Posts: 202
Joined: Sat Jan 03, 2004 4:55 pm
Location: Cleveland, OH

Post by jwalsh »

When creating the login, store the users primary key from the database as a session. Then use that session to filter the data to only show and edit the content related to their ID. Ex.

Code: Select all

$result = mysql_query("SELECT * FROM Articles WHERE AuthorID =" . $_SESSION['userid']);
I'm assuming you've used 2nd or 3rd normal form of relational database design.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

jwalsh wrote:When creating the login, store the users primary key from the database as a session. Then use that session to filter the data to only show and edit the content related to their ID. Ex.

Code: Select all

$result = mysql_query("SELECT * FROM Articles WHERE AuthorID =" . $_SESSION['userid']);
I'm assuming you've used 2nd or 3rd normal form of relational database design.
Don't chew me out if I'm way off or anything but...

Did you just suggest that he stores a user PKID as a PHP SESSION variable...and on every page request which requires authentication/authorization his script should just use the PKID stored in SESSION to determine which pages the user has access to???

Correct me if I'm wrong (are sessions encrypted?) but counldn't an attacker just spoof a PHP session with the PKID of an Admin and then have unlimited access to whatever he/she wants???

Just curious :)
User avatar
jwalsh
Forum Contributor
Posts: 202
Joined: Sat Jan 03, 2004 4:55 pm
Location: Cleveland, OH

Post by jwalsh »

Your fear is justified, although I did it that way for quite a long time without any problem. Since the user spoofing the session would have to have the ID of a user that actually has a live session on the server, it takes a bit more work to spoof the session. Since they are talking about 15 clients, I'm assuming it's not a very huge operation :). Anyway.. it was about the principal.

Nowadays, I create a dynamic token associated with the user. Everytime a user logs in, the token is regenerated, stored in the DB, and the session, then you can match the two up.

Spoofing that token is much more difficult than simply a userid.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

jwalsh wrote:Your fear is justified, although I did it that way for quite a long time without any problem. Since the user spoofing the session would have to have the ID of a user that actually has a live session on the server, it takes a bit more work to spoof the session. Since they are talking about 15 clients, I'm assuming it's not a very huge operation :). Anyway.. it was about the principal.

Nowadays, I create a dynamic token associated with the user. Everytime a user logs in, the token is regenerated, stored in the DB, and the session, then you can match the two up.

Spoofing that token is much more difficult than simply a userid.
Thats the way I do it...

I use a session table and upon authentication I assign...blah blah blah...you already understand the subject :)

Cheers :)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

For even more security (client side - not server side) you can also use a Challenge/Response login process. This basically utilises a Javascript function (it falls back gracefully if JS not supported) to create a unique password hash which can be matched by the server at login.

It's primary purpose is to prevent password being sent in the clear as plain text for any network snooping to see plain as daylight.

Tutorial attached to my sig.

The session token idea above is also good - it's very similar to a form protection scheme to prevent cross site request forgeries. I would also suggest regenerating the session id (and destroying any data associated with the original id) on login, and also on any change in a user's access priveleges. This ensures any potential session spoof is left behind before moving up the access level ladder of your application.

Chris Shiflett is a pretty good reference for security ;) His articles are usually quite simple to follow and avoid too much overloading with technical details.

http://shiflett.org
Post Reply