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

[Calin Iorgulescu]

2010/11/22 Lucian Adrian Grijincu <lucian.grijincu at gmail.com>

> 2010/11/22 Calin Iorgulescu <calin.iorgulescu at gmail.com>:
> > ACK. Ai dreptate, la fel pățeam și eu pe amarok. Din păcate pe elf nu am
> > acces să dau restart la apache, dar din fericire probabil de această dată
> nu
> > va mai fi nevoie, ținând cont că se modifică doar UI-ul. :)
>
>
> Nu știu cât de bine e să fie trimisă necodificat chiar dacă se
> folosește POST. Mi-e să nu se trimită un caracter care să fie utilizat
> în HTTP pentru a sparge câmpurile (sincer, habar n-am ce se trimite la
> POST și cum sunt separate câmpurile).
>
> De asta eu aș opta pentru un:
> * client - js: send(base64(pass))
> * server - java: pass=unbase64(recv())
>
>
Sunt de acord să facem asta și e destul de ușor de implementat. Eu insist pe
partea de GET vs POST fiindcă nefiind folosit în alt loc aș sugera
renunțarea completă la implmenetarea care folosește și GET. În acest moment
nu văd la ce anume ne-ar putea fi de folos. RFC.


>
> Dar apar probleme și la trimiterea parolei către LDAP. Poți investiga
> dacă modul în care trimitem noi parole la LDAP permite și trimiterea
> de parole cu caractere ciudate? Dacă nu ce ar trebui făcut?
>
>
Din ce am putut să vad eu în python parola este handle-uită ca un string și
nu prea este în vreun fel influențată de caractere dubioase. Bind-ul cu
server-ul LDAP se face printr-o metodă apelată (ldap_simple_bind_s parcă) și
din ce am văzut dacă ajunge să fie preluată de python ok parola pe urmă nu
mai sunt probleme când se face bind-ul cu LDAP. Însă până acuma fiind
transmitere prin GET, cum apărea un & în parolă se spărgea câmpul și parola
ajungea secționată în python.


> --
>  .
> ..: Lucian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rosedu.org/pipermail/vmchecker-dev/attachments/20101123/eb1b4ee2/attachment-0001.htm>