Wednesday, June 20, 2007

I HERD YOU LIEK HUNGARIAN

En una suerte de break de la tematica general del blog (?), voy a hablar un poquito de programación.

Básicamente, un tal Joel Spolsky publicó, hace unos 2 años, un articulo llamado Making Wrong Code Look Wrong, ubicado en la dirección http://www.joelonsoftware.com/articles/Wrong.html. Lo que Spolsky sugiere es usar convenciones de codigo para detectar errores más visualmente. Les recomiendo que lean el articulo, cuenta algo interesante sobre el verdadero origen de la nunca bien ponderada notación húngara.
En fin, en caso de que no tengan ganas de leerlo (tl;dr), Spolsky presenta como caso de ejemplo la de proteccion contra scripts en apliaciones web. Si uno, por ejemplo, en un foro, permite el posteo directo de tags html, puede incluirse cualquier codigo de tipo javascript, e incurrir en fallas de seguridad. Entonces propone la utilización de prefijos para diferenciar entre strings seguras de ser posteadas como parte de la página y otras que no, para poder detectar visualmente, que cada vez que uno escribe algo como:

Write usName

uno sabe que esta mal, puesto que "us" significa unsafe, o sea estamos escribiendo una string no segura.

El artículo recibió sus alabos, pero también sus criticas. La principal es que idealmente uno tendria que utilizar un sistema de tipeo más estático y poderoso, que permita distinguir entre cadenas seguras e inseguras y de error de compilacion al intentar postear una cadena insegura.

Ok, esto es cierto. Pero no hace falta tener un sistema de tipeo tan poderoso. La primer solucion sería encerrar las strings inseguras en otro tipo, por ejemplo, en este javascript (lenguaje puesto puramente de ejemplo

javascript Unsafe(s)
{
this.unsafeString = s;
}

entonces, cuando quiero acceder a la string que Unsafe recubre, hago

anUnsafe.unsafeString

y consigo la string. Entonces, toda actividad que requiera postear una string va a fallar con este objeto. El problema de esta solucion es que es muy incomoda. Si quiero sumar dos strings que son unsafe, tengo que hacer algo como

Unsafe(s1.unsafeString + s2.unsafeString)

Incomodo. Una solucion permitida por el sistema prototipico de javascript es la siguiente:

function markSafe(s)
{
s.isSafeString = true;
return s;
}

s sigue siendo una string, y sigue sirviendo para todo lo demas. Toda funcion de escritura no la llamás directamente, sino que haces algo como

function safeWrite(s)
{
if(s.isSafeString == true)
Write(s);
else
BOOOOOOMSDFBHDFSDFDFSDF, o bien,
Write(Encode(s));
}

Esto es un ejemplo de javascript, o sea, probablemente si uno no usa alguna suerte de server side javascript, que es raro, esto no aplica . Si no podemos agregar a las strings fields nuevos, podemos tener una suerte de tabla donde guardamos las safe strings, y despues testeamos si existe esa string en la tabla, y listo (no es lo mas optimo, pero bueno)!

En cualquier caso, si uno se equivoca, va a haber un error visible, no una falla de seguridad. Es mejor un error visible y que la aplicacion no ande que un error visible en el codigo al que uno se acostumbra a no cometer, porque uno siempre los comete.
En fin este fue mi primera blogueada de programación, espero que les haya gustado :nivelx:

1 comment:

niv said...

LOLOOLOLOLOLOLOL