In truth, any of the conditions that require a user to be logged in should check for $_SESSION['user_id']. However, you must try to remember that the applications in the book leave a LOT of room for improvement, in the interest of only including that code required for you to learn the current lesson. Unfortunately, sometimes that means sacrificing some security.
However, also realize that we didn't give up on security altogether. We do show you in the first condition how to test for certain conditions. Plus, (for example), the Edit transaction shouldn't be triggered, because unless the user logged in, AND has permission to edit the article, s/he won't even see the Edit button. Hence, Edit won't be a condition unless the user is logged in.
If you want decent security, then there are really three different places you should use it. First, at the top of any page that requires registered access. If the user does not have the right credentials to view the page, then redirect them elsewhere immediately (usually the login page). Once they log in, you can bring them back to the page they were just on (using session variables, of course!).
Second, you might have certain items on a page that should only be visible by certain users. We use this knowledge to only show Admins the Admin menu item on the home page, for example.
Third, the resulting page you are directed to should have security, to ensure nobody got here by sneaking around when you weren't looking. In this case, your suggestion is quite valid -- you should do a user_id check before committing data to the database, to make sure that person has authority to do so.
As you can probably tell, that would be a LOT of code just for doing security checks. That would add a lot of bloat to the applications. In a future revision, we may introduce objects that will do authentication for you, and would be very modular. Then you could do your authentication checks any time, from any page.
Michael K. Glass
Author, Beginning PHP, Apache, MySQL Web Development
|
Similar Threads
