Apologies in advance here, as I am not sure how best to structure this question…
In php, when you need to control the access of information for a particular section of a site to a user, such as, a member accessing their own profile edit page… you obviously need to perform a database query to check that the specific user logged in has the right to view and edit that specific profile page… (not sure what the terminology is for this)
HOWEVER
imagine the query has been processed and the member now has access to the profile edit page… and now the member wants to update their email address… so they enter their new email address and click update… now should ANOTHER query be performed AGAIN to check that the member has access to perform this update…
I’m sorry if all of that makes very little sense to you… basically what i am asking is, obviously you need to perform a check at the start to make sure a user has the rights to a certain part of a site to perform an update query BUT should you carry out this check again just before you perform the actual update (is there a term on what i am “trying” to describe here)
Thanks for your patience if you’ve managed to read this far
Sure. Only you don’t need to query the database every time. When the user logs in initially, just store whatever data you need in the $_SESSION variable. Then whenever you need to make sure they have permission to do/access something during that session, you can just check the $_SESSION variable instead of performing another DB query.
So say the user logs in and their user ID is 3. Here’s how the login page may work:
<?php
session_start();
// Code to check the user's credentials in the DB
// ...
// OK, store that info
$_SESSION['user_id'] = 3; // user_id retrieved from the DB
$_SESSION['email'] = 'joe@blow.com';
?>
Here’s how the page may work when the user tries to update their email:
<?php
session_start();
// User wants to edit the profile for user_id: 3
if ($_SESSION['user_id'] != 3) {
// Oops, they can't edit this page
exit;
} else {
if ($_SESSION['email'] != $_POST['newEmail']) {
// Email is different, update the DB with the new info
}
}
?>
This isn't a functional example, but I think it will answer your question ... if I understand the question correctly of course.
Ok cool, but if i take this a little further… imagine there was a task that a user had to carry out each day, by simply clicking a button on page that is only available to them… and they could once carry out this task once a day… so first of all the query will be ran to make sure that they have permission to access that task and that they have not already completed it for today… then when they process the task, i think it should check again to make sure that they have access and that it has not already been processed today… becasue they could simply open the task up in 2 separate tabs… then run the task and then run it again in the second tab… but if the check was there BEFORE it made the actual update query, then it would stop this…
Is there terminology for what i am trying to describe… like a “2nd update query validation check”
The session variable is carried over between tabs. The session information is stored on the server, and lasts until the user closes their browser. So you’d really only have to worry about that if the user opened up a second browser all together, or if they restarted the current one.
Either way though, it’s still good practice to check with the DB. I would just check to see if the user has access to that task when they log in. If they do, and they haven’t yet performed that task today (according to the info you got from the DB when they logged in) echo/print the button, if not, skip that part.
Now since a user can still request a page using GET/POST whether or not you provide the form functions to do so, you’ll still want to check again on the page that processes the task. You can probably do it all in the UPDATE or INSERT SQL in one go.
UPDATE task_table SET new_info_column = ‘new info’ WHERE $user_id IN (SELECT user_id FROM allow_users) AND DATE(task_last_performed_timestamp) != CURDATE()
That SQL won’t work as is, and I’m not even sure it’s the best solution, but it can give you an idea as to how you may go about doing the update and authorization in one call to the DB.
