On 12/22/2011 10:05 AM, Paul M Foster wrote:
Not sure how to ask this question... I've always eschewed consulting a
database on page loads to determine if a user is logged in, primarily
because of latency issues. For example, you could store a nonce like the
session ID in a table for a user when they log in. Then each time they
arrive at a page which needs certain permissions to access, you'd check
the table for the nonce and compare it to the actual session ID or
whatever to determine that they're properly logged in. This seems
reasonable but suffers from the lag on the database link's
query-and-response lag time. So I've always preferred some solution
where something is dragged along in a session cookie instead. Maybe
something like the hash of user login, email and user name, which
wouldn't be there unless you'd put it there on login. But this latter
scheme just seems inherently less secure than consulting the table.
Is there any concensus or overwhelming argument one way or the other?
Paul
Why not just use Sessions, that's what the function is for.
http://php.net/manual/en/features.sessions.php There is a good example on this page.
I'm also big on using the session buffer to maintain the current states for
visitors. e.g., one I'm working on now. Obviously, most are binary switches.
Makes condition logic simple.
[confirmedRestrictedUser] =>
[idPassed] =>
[loggedIn] =>
[newRegRecordMode] =>
[pendingRestrictedUser] =>
[recordToken] =>
[regModeLoggedIn] =>
[regUserEditMode] =>
[restrictedMode] => 1
[secrCodePassed] =>
[securityPassed] =>
[sessionStart] => Thu, 22 Dec 2011 12:49:54 -0500
[userType] => restricted
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
