[Pgsql-ayuda] mas sobre traducciones

[Gunnar Wolf]

Manuel Sugawara dijo [Tue, Oct 07, 2003 at 05:56:00PM -0600]:
> > De hecho, en mi opinión, los errores de la BD nunca deben propagarse
> > hasta la pantalla del usuario fuera del periodo de depuración. 
> 
> Esto es un tanto difícil en PostgreSQL. Por ejemplo si alguien esta
> capturando registros que tienen un campo con restricción check y
> alguno de los registros falla, si no le regresas el mensaje de error
> del backend no tienes forma trivial de decirle que pasó a menos que
> dentro de la aplicación reconozcas los mensajes de error del backend y
> se los regreses digeridos al cliente lo cual esta medio roto IMHO (¿qué
> pasa si cambian el mensaje de error en la siguiente versión?) y eso de
> decirle simplemente ``sucedió un error'' tampoco me gusta.

En bases de datos en general, no sólo en Postgres. Lo mejor es dar
información completa. Sin embargo, que el cliente vea un 'ERROR:  Cannot
insert a duplicate key into unique index la_tabla_pkey' o, peor aún, un
'ERROR:  pg_atoi: error in "asdf": can't parse "asdf"' rara vez le va a
indicar algo más que 'Sucedió un error, avísele a alguien que entienda
más que usted'.

> > Además, por seguridad - El soltar a la pantalla del cliente mensajes
> > de error le hace fácil ver la estructura de la BD y los posibles
> > fallos del código que la está manejando, ayudándole a hacer (por
> > poner un ejemplo en las interfaces orientadas a Web) ataques de
> > inyección de SQL.
> 
> Pues si se puede hacer tal vez se merece que se la apliquen :-) Y eso
> de seguridad por obscuridad nunca me ha parecido del todo seguro ...

Bueno, en realidad un sistema que capture todos los casos que pueden
generar errores no revelará información de la BD. Además, si este
sistema lo hace bien, no habrá ningún error que generar. Normalmente,
las inyecciones de SQL revelan un mal diseño o falta de validación del
código, así que hasta cierto punto estoy de acuerdo contigo... Pero aún
así, ¿para qué exponer datos que no tiene caso exponer? ¿Para qué darle
a un usuario final mensajes de error más crípticos (y que probablemente
causarán más estupor o hasta pánico) que los que genera la aplicación?

Saludos,

-- 
Gunnar Wolf - gwolf@gwolf.cx - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF