On Fri, 2011-09-16 at 01:58 +0800, Emmanuel Noobadmin wrote:
On 9/16/11, Always Learning centos@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.