On Fri, 2011-09-16 at 01:58 +0800, Emmanuel Noobadmin wrote: > On 9/16/11, Always Learning <centos at u61.u22.net> wrote: > But wouldn't an added layer of safety be better? Yes of course. > After all, there could be race conditions where two or more users could > cause the application to pass the transaction to the database, which > results in more than the allowed amount being transacted because the > individual values were valid when the application checked. Record locking should prevent that. > > In most circumstances, instead of entering anonymous un-meaningful > > digits to identify customers, look-ups are done with postal code or > > partial address match or partial organisation name match or partial > > telephone number match etc. I love easy-to-use user-friendly systems. > > Which is where AJAX comes in. Typing in a partial address or postal > code brings up, almost instantly on LAN environment, matches without > having to go to a search page or equivalent. No real different between an Ajax screen and a normal HTML screen (with CSS) showing the matches. > > I use the SQL privileges for tables and enable only the SQL verbs > > required by a user. I certainly do not want a user being able to 'drop' > > a table. Only I can do that. > > I wasn't referring to that kind of problems but normal INSERT/UPDATE. That too. If a user does not need to perform a SQL function then that user has no authorisation to use the SQL verb. > > In my systems such actions could not happen. No user gets permissions > > they do not genuinely require. If the programme specification says no > > 'overdraft' then funds can not be transferred out of an account if that > > account balance would go negative. > > Assuming everything works as expected, no bugs, no intentional hacks > and nobody edited the application source without your knowledge ;) User can not change READ ONLY programme files. > It's never too late to stop junk from getting stored. Early prevention > might be better than late prevention, but any prevention is definitely > better than none! :D Robust data validation is always an essential requirement for any data input procedure. There is no point in running a super-doper system if it can be contaminated with bad data. Acceptance of bad data makes a mockery of the entire system. > > That is why I always try to wreck my programmes by entering invalid > > data. If I fail to wreck my programmes there is a reasonable certainty > > others will fail too. > > But it doesn't guarantee that somebody/something else can't. I think it means no one else can :-) What I never tell users is every programme routinely logs every user's details and activities. So if things go wrong, I read the application's log file. > After all, we're only humans and I believe all of us have blind spots > which can allow edge cases to escape testing. No point in me 'escaping testing' of my programmes. I prefer them going wrong in front of me and not in front of the users. Hence my vigorous testing policy when I become the user. -- With best regards, Paul. England, EU.