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.
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.
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.
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.
$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???
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.
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
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.