Leaderboard

Sessions have expiration that you can set, as do cookies, so you have a couple different ways of handling it. I don't want to complicate things, because the way session files are cleaned up is complicated, and highly dependent on the amount of traffic a site has. Also, keep in mind that a session does not equal access. A session is just some stored data associated with a browser/client. So for example, let's say you allow access to a site via login, and you want that access to expire after 15 minutes of inactivity. One way to handle that is to have a last_request column in the users table which stores a timestamp. You can also alternatively, store that value in the $_SESSION itself. When a "logged in" user makes a request, you have an access check that reads this value and does some simple math against it (timestamp - last_request) and depending on the amount of time that has passed, you can allow the request to proceed, or if too much time has elapsed, remove whatever session data you have that indicates this user logged in successfully and redirect to the login page. Sessions are just a way to simulate a persistent connection across HTTP requests. They can facilitate your security scheme, but they aren't providing access or rejection of anything. I would suggest reading about cookies. Again they are the preferred method of session identification. As long as you only allow secure sessions (and cookies) you can avoid a lot of security gotchas, but cookies themselves can have expiration. Just keep in mind, that cookies like anything else that comes from the client can not be trusted. The client should honor the cookie settings when the server tells the client to set a cookie, or expire it, but that doesn't mean that the client will do that. For normal browsers, they certainly work as per the RFC for cookies specifies, but the request could come from some hacker who is using a modified browser or browser simulation code, that looks to your server like a regular browser, but isn't. In general, any data you get from a client has to be considered suspect, and that includes all forms of data the server gets from the client including the data in $_COOKIE. Most systems will include a variety of different methods to facilitate security. For sessions, another best practice is that anytime you escalate privilege (login, access to change secure data like a password, or financial transaction) your code should regenerate the session id, and re-prompt for authentication. I could go on in the abstract about this topic, but I really only intended to try and get you a jumpstart on your understanding, which I hope I did successfully.

Now you have told us the actual context it makes a lot more sense than having reusable member IDs. You also introduced a couple of other attributes that would be stored in the "berth" table (renamed from member_no) viz. Size and Pier. Size required would need to be known at time of allocation to a member. Reallocation of a different berth would need to be a custom transaction, allocation on insert could be a trigger function, de-allocation could be a foreign key cascade option. Your assertion that a member is deleted when their boat changes is FUBAR. Change, or add, a record in the member boat table. The boat size in this table would determine the size required for the new berth. or

If you have the information in your database, why do want to store it again in JSON format. Although I expect the drivers will be delighted to be handed their deleivery schedule printed in JSON format. You cannot correctly compare dates in m/d/Y format