Newsgroup: it.comp.lang.visual-basic
Titolo: ADO, ConnectionString e Password in chiaro

Ho appena modificato ESP0DAMA per copiare negli appunti il testo di un
qualsiasi ramo della struttura del database. Mi interessava, in particolare,
la proprietà ConnectionString di ADO. Questa è lunga come la fame e la
TreeView non la mostra tutta ed ecco il motivo di metterla negli appunti.
Ci va e ci va completa, con l'eventuale password in bella vista e in
chiaro... :-(
E' vero che chi ha aperto il database la password la doveva conoscere (ma in
un applicativo non è detto), ma non mi pare logico che se l'operatore
autorizzato si alza per un caffè lasci (solo perchè quel programma mostra
quella proprietà) alla mercè di chicchessia un'informazione che, per quanto
poco sicura, è pur sempre riservata...
PS: Ovviamente ( :-P ) questo con DAO non avviene. Ok, fermi lì, capisco,
altra tecnologia...

 un'informazione che, per quanto poco sicura, č pur sempre riservata...
Non ho capito.
Non conosco ESP0DAMA, ma se non sbaglio č uno strumento di
sviluppo/amministrazione del db, giusto?
Per cui, che la password sia o meno visibile č una scelta di chi ha
sviluppato il sw stesso, non una peculiaritą di Ado piuttosto che di Dao.
A parte questo, va considerato che una pw all'interno di una
connectionstring č 'intercettabile' con un banale sniffer freeware di rete,
a meno che non si usi una connessione protetta, ad esempio SSL.
Quale unica ulteriore forma di sicurezza, alcuni provider non supportano il
PersistSecurityInfo, per cui la password, dopo l'apertura della Connection,
viene tolta dalla ConnectionString (che, contrariamente a quanto si pensa, č
una proprietą molto 'viva', e non una semplice variabile public della classe
Adodb.Connection).
Ma forse qualcosa mi sfugge della tua osservazione...
Ciao
Alberto

 Ma forse qualcosa mi sfugge della tua osservazione...
No, credo che tu abbia capito perfettamente, solo che tu ritieni accettabile
quanto a me lascia, almeno, perplesso. In altre parole, secondo me la pwd
dovrebbe servire (come immagino accada per DAO) esclusivamente per accedere
al database, ma non dovrebbe essere riportata da nessuna parte _dopo_ che si
è fatto accesso al database stesso. Che poi sia più o meno facile scoprire
la pwd di un database, beh, questa è altra storia...

 chiaro... :-(
non ho ben capito.
Se ho ben capito, invece, tu non fare Clipboard.SetText connectionstring
direttamente.....
fai la SetText elaborando la connectionstring ed eliminando la proprietà che
contiene la password, semplicemente ciclando la collection Properties da 0 a
Properties.Count - 1.
però non sono d'accordo. ESP0DAMA è un utility per lavorare coi database, ed
è giusto che contenga la pwd.
good coding!!!
-- 
Alletun
"Io lo so che accadrà. La voce sussurra nei miei pensieri di Jair, Rone,
Allanon e soprattutto nelle Mortombre.
Sussurra segreti che mi sono tenuti nascosti, nella grigia oppressione
di questo giorno e nell'oscurità caliginosa di quello che mi aspetta.
Saremo distrutti. Tutti."
Brin Ohmsford - La Canzone di Shannara - T. Brooks

 database, ed č giusto che contenga la pwd.
... ma vedi la risposta ad Albe.

 stesso.
Aggiungo "proprio perchč la CS č dinamica", come giustamente hai fatto
notare.

> proprietą che contiene la password
Ok, rileggendoti meglio, vedo un suggerimento al comportamento di ESP0DAMA.
Grazie, lo applicherņ, ma, ribadisco, dovevano pensarci, alla fonte, loro,
gli sfaticati... ;-)

 notare.
Prova con Persist Security Info a False.
Ciao
Alberto

 alla fonte, loro, gli sfaticati... ;-)
Beh, è una scelta che puoi fare tu.
Un buon software deve essere in grado di ripristinare una connection caduta,
dopo ad esempio un distacco del cavo di rete, senza inconvenienti per
l'utente.
Quindi, da qualche parte la password va conservata, perchè alla
riconnessione va inviata nuovamente.
In questo caso, il PersistSecurityInfo a false (come è di default per molti
provider), ti costringe a mantenere una variabile String con la password, e
a riattaccarla alla connectionstring ogni volta.
Questo, ad esempio, è un caso in cui poter avere la password 'statica'
sarebbe comoda.
Ciao
Alberto

 gli sfaticati... ;-)
uao, mi metti nei credits, allora?!?!?!?!
:-))))
a parte scherzi, io personalmente trovo giusto che nella connection-string
ci siano tutte le informazioni necessarie per la connessione al db. Quanto
dice Albe, tra l'altro, dà anche la possibilità a quanto pare di toglierla.
Io a questo punto darei la possibilità di fare il copia della
connectionstring con o senza password.
Domanda, tu che adori ADO: ma la proprietà che contiene la password si
chiama sempre allo stesso modo?
non credo, o sbaglio?


 non credo, o sbaglio?
Non ti seguo... La ConnectionString č la ConnectionString
Urca... ora vado a vedere le proprietą estese, che racconto anche quelle...


La sintassi della connectionstring dipende dal provider.
Quanto al campo Password, non so se il tag sia sempre lo stesso, ma se non
sbaglio fra Sql-Server e MySql c'č differenza.
Per Jet non so.
Ciao
Alberto

 Alberto
esatto, fra mysql e sqlserver non cambia. Per Jet mi pare diventi una cosa
tipo "Jet.OleDB.Password", più o meno. Morale della favola: non puoi sapere
a priori come si chiama la proprietà che contiene la password, per cui come
mai eventualmente ad escluderla da un eventuale copia&incolla?????
:-((
uff, a meno che, brutalmente, non usi una InStr della stringa
"Password".....che brutto.....
uhm uhm, good coding?


 Per Jet non so.
Ahhh, ok, ho capito. Me ne sono strabattuto :-P
Ho cambiato in tutte le "PASSWORD=xxx;" e "PWD=xxx;" le "xxx" in "???"
Se poi uno la chiama "KEYPASS=xxx;" che vada a dormire.

 esatto, fra mysql e sqlserver non cambia.
Giusto. Neanche per Access, apparentemente.
MYSQL
Provider=MySqlProv.3.0;Data Source=db1;Password=motdepasse;User
ID=utente;Location=pv-02
SQL-Server/MSDE
Provider=SQLOLEDB.1;Password=motdepasse;Persist Security Info=True;User
ID=utente;Initial Catalog=db1;Data Source=pv-02
JET4
Provider=Microsoft.Jet.OLEDB.4.0;Password=motdepasse;User ID=utente;Data
Source=d:\db1.mdb;Persist Security Info=True
Ciao
Alberto

 Se poi uno la chiama "KEYPASS=xxx;" che vada a dormire.
... ma se una pwd contiene il ";" ?
Vedo che Access me la rifiuta, ma l'autenticazione di SQL Server (che non
provo nemmeno!), per esempio...? :-(

Il ; č un carattere di chiusura, ergo non te lo riconosce valido
per essere impostato come carattere password.
sono caratteri validi piů o meno quelli che usi per le e-mail
da 0 a 9 da a a z uppercase e lowercase, _ - @ e pochi
altri che non ricordo ... tutto da smentire ... ovviamente.
Ciao
Andrea

[Andrea Moro = 
circ...@privacy.net
 in c37pb0$rjb$
1...@lacerta.tiscalinet.it
]
ha scritto:

Mi tornerebbe, solo che la guida (per esempio per NewPassword, un metodo DAO
per cambiare la pwd a un database) cita:
"Le stringhe vecchiapassword e nuovapassword possono avere una lunghezza
massima di 14 caratteri e possono contenere qualsiasi carattere, eccetto il
carattere ASCII 0 (Null). "
Cin-Cin! ;-)

mmmm ... dao è per me come il mussulmanesimo ... non
sò dove sta di casa ... o meglio lo sò, ma non lo pratico.
Quindi prendo per buono quello che dice la guida partirei
dall'assurdo che sia vero ... ma farei delle prove ;))
Ciao
Andrea

 Cin-Cin! ;-)
uhm uhm, aspettate, ho qualche dubbio.
Perchè volete lavorare sulla stringa della connection string. Bisogna fare
il parsing della stringa, e questo credo sia un po' male: lento e c'è il
problema del ;
Io farei quanto segue:
Dim i As Long
Dim Archivio As ADODB.Connection
Set Archivio = New ADODB.Connection
Archivio.ConnectionString=pinco_pallino
For i = 0 To Archivio.Properties.Count - 1
    Msgbox Archivio.Properties(i).Name
    If UCase$(Archivio.Properties(i).Name)<>"Password" Then
        'Salto la password se non la voglio
    End if
Next
Questo è un ciclo che dovrebbe scandire (non l'ho testato) tutte le
proprietà di una connection-string.
Quando incontro la proprietà che contiene la password, se non la voglio
semplicemente la salto.
no? non va bene? mi sfugge qualcosa?


 no? non va bene? mi sfugge qualcosa?
Non voglio saltarla, voglio che il suo valore (la pwd riservata, appunto)
non venga esposto in chiaro...

 Proprietà Estese). Ti tolgo dai Credits. :-P
sì, hai ragione, il tuo post l'ho visto, ma non ho mai visto ESP0DAMA, mi
rifiuto di usarlo.....
;-)))))
cmq, ok, evidentemente non ne so abbastanza dell'ADODB.Connection, mi affido
alla tua esperienza in merito.
Attendo fiducioso la prossima release di ESP0DAMA per *non* poterla
provare......


 provare......
L'ho mandata ora, anche se non è ancora stato pubblicato un aggiornamento
del 25/2, ma tanto, a te chettefrega?! :-P