Question Re View/Edit/Delete Users In Ch 10

[foppong]

Hello,

 

I have studied the method presented in chapter 10 for viewing, editing, and deleting users. However, I am a bit concerned about when a user clicks the link to edit or delete, the user ID is passed via the URL to another page.

 

Ex here: [from view_users.php]

 

<td align="left"><a href="edit_user.php?z=' . $id . '">Edit</a></td>

<td align="left"><a href="delete_user.php?z=' .$id . '">Delete</a></td>

 

I have found that I can simply change that ID value and perform an edit or delete on another user. This is a concern especially if that user is not authorized to make that edit or deletion. I believe this example is meant for an admin, but I want to pass this functionality a level below to a group leader that can manage their users.

 

My question for the forum is how could this method be made more secure? I've been racking my brain on this can and can't seem to figure out the best approach. I know passing session variables to the edit and delete scrips would be most secure, but how can I bind the selection of a user (and their respective ID) from a row of names to a specific session variable and then call on that session variable from the edit and delete.php scripts to perform the edit or deletion?

 

I appreciate any thoughts.

 

Thanks,

[Edward]

Hi fappong, you are quite correct this method is not secure but these were only some basic examples mentioned in chapter 10 if you just keep working through the book, once you get up to chapter 18, the User Registration Example most of your questions will be answered. Yes you are right sessions or even database stored sessions would be the most secure way of storing information. Keep reading, keep reading..

[foppong]

Hey Edward,

 

I've actually read the entire book, and even most of the advanced PHP book. The key difference here is that in chapter 18, a user is logging in with a email address and password. So using those two parameters, we query the database and return the unique user ID (via session variable if desired) and that's fine. More so, that's done using a form.

 

The difference here is that say I am the manager of 10 employees. I have a view users page where I can view all my employees. It doesn't seem practical to be forced to enter a email/pass/or any combination every time I want to edit or delete a user. More importantly, there is a table and row of data - the question is how can we pass that row selection (securely) to the back end for php processing?

 

I could set up a form, but that defeats the purpose of a clean UI where a manger can simply use the datagrid (or table) to edit/delete their employers. Alternatively, I had thought about encrypting the id and recovering it after it's passed through the URL, but I'm not sure how practical that is. If you feel chapter 18 still addresses my above comments, please explain.

 

I really wonder what Larry has to say on this as well. I know there must be a best practice out there used by the pros. .

 

Thanks,

[Edward]

I'm sorry i jumped to the conclusion that you had read the whole book, i see what you are saying here. If i am understanding what you are saying correctly, then you will probably need javascript combined with some ajax requests to keep this all cleanly flowing on the same page. Javascript and Ajax are things that even i am learning myself right now, so i don't have much more to say.

 

Larry will be on soon,

[foppong]

So, I think I figured out a solution. I'll see if I can explain it.

 

Instead of passing the z variable in the URL, I actually pass a <form>.

 

 

// Fetch and put results in the JSON array...

while ($stmt->fetch())

{

$json[] = array(

'Name' => $nOB,

'Email' => $eOB,

'Gender' => $genOB,

'Position' => $posOB,

'Edit' => '<form action="edit_user.php" method="post">

<input type="hidden" name="x" value="' . $idOB . '" />

<input type="submit" name="submit" value="Edit"/></form>';

 

} // End of WHILE loop

 

When the user clicks the submit, it takes them to the edit_user.php page. On this page, I had to make some modifications since now the user ID will be passed via a form instead of the URL.

 

 

if ($_SERVER['REQUEST_METHOD'] == 'POST' && isset($_POST['z'])) // Confirmation that form has been submitted from view user page

{

$id = $_POST['z'];

}

elseif ($_SERVER['REQUEST_METHOD'] == 'POST' && isset($_POST['x'])) // Confirmation that form has been submitted from edit_user page [rest of code is similar to ch 10]

{

$id = $_POST['x'];

 

}

else

{

// No valid ID, kill the script.

echo '<p class="error">This page has been accessed in error.</p>';

include '../includes/footer.html';

exit();

}

 

Seems to be working thus far. I know this is still not the most secure method, but at least a user can't simply enter the id of another user in the URL and proceed to edit their page.

 

I still value any feedback.

[Larry]

The problem isn't in how the ID is being passed. It's fine--and normal--to pass that in the URL. Storing it in a session just adds unnecessary complexity. Using a form makes it harder to hack, but no more secure than the URL.

 

The security has to be implemented in the script that does the action deletion or editing. Specifically in this case, you would create a system in the database that reflects what group leader/manager is in charge of what employees. Then the script that does the actual editing and deleting would confirm that the current user has permissions to alter the given record.