On Sat, 2007-03-10 at 08:07 -0300, Jorge Godoy wrote: > omar <omar2@xxxxxxxxxxxx> writes: > > > I'm curious what people think about the following statement considering the > > database typing talk being brought up here. My experience is that more times > > than not I have to put data validation in my client code even when it's > > available on the server, if for no other reason that users don't understand > > what foreign key violation, etc messages mean. It begs the question of > > whether it's really necessary on the server or not. SQLite seems to take the > > position that it isn't since there is no referential integrity and the > > following. To be honest, there's a lot of power in the ability to view > > everything as a string, with of course proper data validation. > > I believe that data validation is essential at the server side. The ideal > situation to me is something like data validation on server, errors / > exceptions being risen and then catched by the client code that will translate > them to a suitable message. > > Inserting data validation on client side helps with simple input and eliminate > the average number of roundtrips needed for getting the data stored, but > shouldn't be the only validation done. > I completely agree and would add that I also prefer to use server side session cookies to validate the authenticity of the remote user. Stopping man in the middle, client spoofing and SQL injection are all good reasons to use multiple levels data and remote user verification. One other good trick is to use table permissions to only permit read only database access, and in many cases from a view not the actual table. Paranoia and systems administration/development go well together in my humble opinion. Keeping the server and data safe is a big part of our responsibility. I give cheers to PostgreSQL developers, in developing the excellent tools they have provided thus far and would like to encourage them to keep up the excellent trend.
