Re: To session or not to session

* Andy Pieters <mailings@vlaamse-kern.com>: > I forgot to mention some context related stuff. > > 1. This is for distribution, so wether or not session will actually be > avaiable is something I cannot know. As I noted in an earlier post, you can probably assume sessions are available on any given PHP install; it will be rare to find one without them. Built-in session management is one of the reasons PHP has thrived. (ever try sessions in perl? which library do you choose? or do you roll your own? PHP's just work, without needing to choose.) As I also mentioned, make a note of it in your install docs: "This application requires that your PHP installation has session support." And include some information on how to check that it's available. > > Right now I am giving a trust factor of 80% to POST and 0% on GET. What > > trust factor should I apply to SESSION > > 2. These trust factors are applied AFTER login verification. (The login is > verified with a cookie that holds a unique id I sent when the user loged on. > This is validated against a database. The unique id's live span is extended > after each request) So, are you validating POST'd data from verified users? 'Cause if you're not, there's still nothing preventing a verified user from uploading tainted data (of course, you may be able to determine who did it and when... assuming the tainted data didn't corrupt your DB). POST and GET are inherently untrustworthy. -- Matthew Weier O'Phinney | WEBSITES: Webmaster and IT Specialist | http://www.garden.org National Gardening Association | http://www.kidsgardening.com 802-863-5251 x156 | http://nationalgardenmonth.org mailto:matthew@garden.org | http://vermontbotanical.org