differentiate between the two users

Ali_baba

Hello,
I am writing a script that will let users to do the database functions (insert, delete and so on....). There are around 50 - 100 users. It is possible that there can be more than one users at a time accessing and doing their stuff with the database.
How it is possible to differentiate between two users if they are entering the data at the same time? Will only SESSIONS do the trick or do I need to know something else too?

If SESSIONS can only do the job then can you please see my script?

index.php

<?php
header("Location: login.php");
exit;
?>

<form name="entryform" method="post" action="authorize.php">
<div class="fond">
  <table align="center">
  <tbody>
    <tr><td>&nbsp;&nbsp;</td></tr>
    <tr>
    <td>Username:</td>
    <td><input type="text" name="username" maxlength="10" /></td>
    </tr>
    <tr>
    <td>Password:</td>
    <td><input type="password" name="password" maxlength="10" /></td>
    </tr>
    <tr><td>&nbsp;&nbsp;</td></tr>
    <tr>
    <td><input type="hidden" name="verify_authorize" value="ok" /></td><td align="right"><input type="submit" value="Login" /></td>
    </tr>
    <tr><td>&nbsp;&nbsp;</td></tr>  

  </tbody>
  </table>
</div>
</form>

authorize.php

<?php
if ($_POST['verify_authorize']=="ok") {
session_start();
session_register("SESSION");
require ('application.php');
$result = mysql_query("SELECT COUNT(*) FROM users WHERE username='$username' AND password='$result_password'"); 
// COUNT because you don't need the actual data in the row, just whether there 
// is a row there or not. 
$result_count = mysql_result($result,0,0); 
if($result_count>0) // A successful match against a database record. 
{ 
$SESSION["user"] = $username;
$SESSION["ip"] = $REMOTE_ADDR;
$SESSION["time"] = time();
echo "
    <table border=\"0\" align =\"center\"> 
    <tbody> 
    <tr> 
    <td>You are authorized.</td> 
    </tr> 
    <tr> 
    <td> 
    <form action=\"users.php\" method=\"post\" />
    <input type=\"text\" name=\"senduser\" value=\"$username\" />
    <input type=\"submit\" value=\"Login\" />
    <script language=\"text/javascript\"></script> 
    </td></tr></tbody></table>   

    </body>
    </html> ";
} 
else 
{ 

echo "error";
}

After authorize.php, the user will be in the page where he can do his job (addition, deletion....). Here how will I know that he is user x, not user y who is logged in at the sametime? Is session_start() line on every page enough?

_theworks

hmmm tricky situation..

What if you made it so wen the users do there DB stuff they dont interact directly with the DB . like say instead of having their commands going straight into the db have them sent to a 'temp' file of somesort or even a temp directory with a individual file for each user which is then read, validated and enterd into the Db by a 5min crontab?

Ali_baba

Thanks for your reply
no there should not be any 5 minutes delay. Everything should be in real time.

Roger_Ramjet

Yes, you need session_start() in every script that uses sessions.

The use of session register() is deprecated and should be avoided. RTFM for the reasons.

You need to use mysql real escape string on the user input to prevent sql injection attacks, especially when it comes to the username and password submitted for a login. Without it, hacking your login is too easy.

The best method for security purposes is to have a read-only user account that you use to connect to the db for login - hackers can't do much even if they detect that username and password. You then have other user account with varying privileges that are used for wider acess to the db.

Your best solution for this problem of tracking users is to give each a mysql user account that they use for all db connects after they have been verified. The user name and password can be different from their login, just add fields to your users table to contain the mysql user data and store them in session vars once user is authorised.

Ali_baba

Roger Ramjet wrote:
Yes, you need session_start() in every script that uses sessions.

The use of session register() is deprecated and should be avoided. RTFM for the reasons.

You need to use mysql real escape string on the user input to prevent sql injection attacks, especially when it comes to the username and password submitted for a login. Without it, hacking your login is too easy.

The best method for security purposes is to have a read-only user account that you use to connect to the db for login - hackers can't do much even if they detect that username and password. You then have other user account with varying privileges that are used for wider acess to the db.

Your best solution for this problem of tracking users is to give each a mysql user account that they use for all db connects after they have been verified. The user name and password can be different from their login, just add fields to your users table to contain the mysql user data and store them in session vars once user is authorised.

Thanks Roger for your detailed reply.
I changed my session variable to $_SESSION.
The database link will be given only to those people who are going to use it.
What I am doing is that, I save the loginname only in the variable and then pass it among the pages. When the data is entered (and saved), then the login name is going to be save as well. I also used time in session with username. Checked this logic at home, and it worked ok.
BTW, I copied and saved your advice, and I will refer to them if I am going to make a public DB 🙂

_theworks

if you make a site where users can interact with the DB easily your leaving yourself open for attacks.

Roger_Ramjet

That's one way to do it and should work fine enough for your purposes; and on an intranet.

One thing you should know about though is the mysql (and most db) facility to default a column value to the curent user(). Every time they enter or update a record it automatically records who did it.

Of course this only works if each person connects with an individual user account, but when it's 100 users then this should be the case anyway. They are not all going to need the same access to the db, I mean it may look like it now but down the track you are going to find that only some people should be allowed to input or update certain data, or even read only certain columns or certain tables. When it's a 100 user then some manager is going to insist on this one day.

This applies even more when it is a public page.