From: | Manuel Sugawara <masm(at)fciencias(dot)unam(dot)mx> |
---|---|
To: | Gunnar Wolf <gwolf(at)gwolf(dot)cx> |
Cc: | Alvaro Herrera Munoz <alvherre(at)dcc(dot)uchile(dot)cl>, Martin Marques <martin(at)bugs(dot)unl(dot)edu(dot)ar>, pgsql-ayuda(at)tlali(dot)iztacala(dot)unam(dot)mx |
Subject: | Re: [Pgsql-ayuda] mas sobre traducciones |
Date: | 2003-10-07 23:56:00 |
Message-ID: | m3n0cc7gbz.fsf@conexa.fciencias.unam.mx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Gunnar Wolf <gwolf(at)gwolf(dot)cx> writes:
> 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.
> 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 ...
Saludos,
Manuel.
From | Date | Subject | |
---|---|---|---|
Next Message | Gunnar Wolf | 2003-10-08 00:02:29 | Re: [Pgsql-ayuda] codificacion con bytea |
Previous Message | Manuel Sugawara | 2003-10-07 23:18:17 | Re: [Pgsql-ayuda] mas sobre traducciones |