On 03/03/2014 02:18 AM, Dan Egli wrote: > Anyway, that's how I do things. And it seems to work. Because the code is > executed and not viewed, no one knows the exact format I use (and I do > change it from project to project) for the token ID, so they can't ape it > by editing/hacking/forging a cookie in their browser. Even if they did > manage to view the cookie and get the token ID, they first have to KNOW > it's the token ID, and not some other numeric value (most tokens I write > are just large numbers with specific modulus requirements), then they have > to verify which field is the timeout field (with multiple integer fields, > all of which are unlabeled, that's not so easy). That's required so they > can bypass the timeout requirements. And in case you're wondering, yes, > logging out normally (by clicking the logout link) does delete the cookie > from the computer. The logout link would normally take you back to > login.php?act=logout. When login.php runs, if the act element of the > $_REQUEST/$_GET/$_POST array is logout, it calls session_destroy() which my > understanding is tells the browser to delete the cookie that was created by > session_start(). So far it's worked well, and I've had no major complaints.
Yes, good practices, from what I can see. Though PHP certainly doesn't go out of its way to make life easy for a programmer. I just read this random blog post, and it's given me a migraine (I had one before I started reading this article, but it's now a lot worse): http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ While I've never really enjoyed PHP, I had no idea PHP had so many gotchas and pitfalls. The article goes on for pages and pages with specific examples that certainly are worrisome. Not trying to troll here; I personally don't use PHP at all, and maybe the author is off-base. I dunno. I know many of you are very good at wielding PHP effectively. /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
