On Tue, April 5, 2005 2:24 pm, mailings@xxxxxxxxxxxxxxxx said: > I have been doing all my design by using POST to transfer user data and > GET > for user changeable variables. > > I would like to know what you guys think of using SESSION in production > sites. GET, POST, SESSION, Whatever it takes. > Right now I am giving a trust factor of 80% to POST and 0% on GET. Nooooooooooooooooooooo! POST is *NOT* *NOT* *NOT* more secure than GET! Okay, maybe a total goof can figure out how to munge GET, but can't figure out how to "Save As..." and edit the HTML to POST whatever they want. So you can put POST at 1% trust factor, if GET is 0%. Whoopie. > What > trust > factor should I apply to SESSION Are you on a DEDICATED or SHARE server? In either case, somebody out on the Internet has to break into your server to get to your SESSION data. BUT! If you are on a SHARED server, then *all* other users with a login can, without *too* much effort, write a PHP script to read your SESSION data. You really can't prevent this, in practical [*] terms. Think about it. If *your* PHP script can read the SESSION data, then *their* PHP script, which runs as the same user on the OS, with the same permissions can *also* read the SESSION data. * Impractical nitpik: You could set up a separate pool of Apache processes for each host/domain, with a different User setting in each httpd.conf for each host/domain/httpd, but that's going to make your shared server pretty impractical for *MOST* uses where you want a shared server in the first place. > Should I implement a SESSIONless feature in case SESSION is not available? If SESSIONs are completely unavailable, from both Cookies and trans_sid being turned *OFF* in php.ini, and/or no trans_sid and the user denying Cookies... I wouldn't recommend trying to roll your own. Just require some kind of session support, or call it quits. Do test with Cookies *OFF*, however to be sure it works right with non-Cookie browsers, and the Session ID should be passed in the URL. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
