On Sat, 2007-03-10 at 08:07 -0300, Jorge Godoy wrote:
> omar <omar2@omnicode.com> 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.