Page 1 of 1

Create Logins for Clients Only to See There Pages

Posted: Tue Oct 18, 2005 6:01 pm
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

Posted: Tue Oct 18, 2005 10:24 pm
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.

Posted: Tue Oct 18, 2005 10:33 pm
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 :)

Posted: Tue Oct 18, 2005 10:38 pm
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.

Posted: Tue Oct 18, 2005 11:00 pm
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 :)

Posted: Wed Oct 19, 2005 5:54 am
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