[vmchecker-dev] [vmchecker] Bug caractere speciale în parolă

[Calin Iorgulescu]

2010/11/23 Claudiu-Dan Gheorghe <claudiugh at gmail.com>

> Am implementat ceva in legatura cu parolele anul trecut. Din cate stiu
> mergea pe cazurile pe care se plangeau oamenii, iar majoritatea erau
> caractere de genul #,$, etc. Solutia a fost sa fac urlencode parca.
>
> Daca vorbim de diacritice, e cu totul altceva. Aici intervine
> encodingul caracterelor, care momentan e posibil sa fie ASCII, iar noi
> trebuie sa il fortam in utf8. Problema este ca aceste caractere trec
> prin diverse medii/limbaje/canale de comunicatie, si trebuie impus
> peste tot: HTML, python, LDAP, etc. Solutia cu base64 merge doar intre
> client si server, insa asta nu asigura o solutie end-to-end.
>
> * In HTML e usor de impus un encoding:
> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
> sau fortezi headerul
> Content-Type:   text/html; charset=utf-8
>
> * In Python sunt mai multe solutii. Eu pun in top-ul scriptului:
> # This Python file uses the following encoding: utf-8
>
> * In LDAP, habar nu am cum impui encodingul.
>
> Cred ca ar fi de folos un articol[1] despre character encoding si Unicode.
>
> Sanatate, numai bine,
>
> [1] http://www.joelonsoftware.com/articles/Unicode.html
>
> --
> Claudiu
>

Salut Claudiu,

Ok, dar chiar are sens să lăsăm login-ul să se facă prin GET? Adică sincer
să fiu e singura funcție care se face prin GET. Mi se pare atât un risc de
securitate cât și o chestie un pic atipică. Just my $0.02.

Mai exact, poți să vezi un moment în viitor în care ne va trebui GET pentru
vreo funcție delegată către services.py ?

Călin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rosedu.org/pipermail/vmchecker-dev/attachments/20101123/e6315be7/attachment.htm>