Newsgroup: it.comp.lang.visual-basic
Titolo: File di configurazione programma

Mi sorgeva il dubbio su come andarmi a parare se
l'utente dell'applicazione mi apriva a mano il file
di configurazione e mi cambiava i parametri.
Una utility interna di fixing al fine di verificare se
esiste o meno un valore valido l'ho già implementata;
il problema è quando applicarla.
Volevo trovare un modo elegante per memorizzarmi
la data dell'ultima modifica da pannello di configurazione
e confrontarla con la data ultima modifica del file, ma
il punto è .... dove memorizzo la data.
Niente db, perchè se sto correggendo il file di configurazione si potrebbe
anche essere verificato un
cambiamento dei valori di connessione e non avrei
modo di recuperare la data memorizzata.
Un file dentro la cartella del programma ... facile da
capire ... un file dentro un'altra cartella ... di sistema
perchè le altre verrebbero sgamate subito ... poco
mi piace ... o altro sistema che non mi viene in mente.
Ideee
--
Saluti
Andrea Moro

 ha scritto nel messaggio
news:bi7v6b$6acph$1...@ID-61006.news.uni-berlin.de...


 ha scritto nel messaggio
Ricordo i dubbi di un lavoro precedente:
Se l'operatore cancella l'exe ?
Se il secondo esegue l'update dei dati updadate un secondo prima ?
Se un utente smaliziato va a modificare il file.xml dove sono inseriti i
dati di config. del programma?
Mettiamoli nel registro. Hem, uno č pittosto smalizziato, non credo siano
sicuri neanche lě
....
.....
giuseppeD
---------------------------------
"Solo io posso salvare il il calcio" - Disse colui che con due baci aveva
eliminato due dei suoi.

 il punto è .... dove memorizzo la data.
Registro di sistema, in due punti diversi e non in chiaro,
magari usando un long convertito in esadecimale.
A meno che non sia uno che sta cercando apposta di
craccare l'app, non credo che possa metterci le mani.
Bye, G.

Mumble ... si non avevo pensato al registro perchè di natura lo
detesto ... mi piaccino le mie cosine belle oridinata ;)
Ma anche se volesse cracckare l'applicazione, dubito seriamente
ci farebbe qualche cosa con dei valori in chiaro che gestiscono
qualche opzione del programma (e non certo la sicurezza) che
è demandata totalmente a sql server e n tabelle :)
Quindi o mi buchi sql server, e allora li sono cazzi MS e non
miei ... oppure che mi metti uno 0 al posto di un 1 ... ci fai
poco ;)
Ciao
Andrea

 di configurazione e mi cambiava i parametri.
Mi sembra un pò paranoico, ma invece della data, potresti utilizzare una
tecnica tipo checksum crc etc...
Ogni volta che il programma accede ai dati controlla che il checksum sia
esatto, se lo è imposta i nuovi settaggi nel file di configurazione e poi
ricalcola il checksum del file stesso. Se il checksum è errato, allora
informa l'utente che è stata fatta una modifica manuale ai files di
configurazione, cancella il file e reimposta i default.
Il checksum potrà essere memorizzato facilmente in un file nella dir del
programma (tanto se l'utente non ha i sorgenti non può farci niente). Oppure
(se di lunghezza fissa) anche alla fine del file di configurazione stesso.

Anche questa può andare bene ... ma il fatto è che il file
per quanto vuoi modificarlo la lunghezza è sempre quella.
Quindi se non erro, se un 1 lo trasformi in 0, non credo
che il checksum cambi. I byte sono sempre quelli.
Quindi andrebbe vanificato il discorso.
Andrea

 che il checksum cambi.
Ma certo che cambia, anzi deve cambiare (è una specie di prova del nove)
:-))

Immaginavo che tu mi rispondessi così ... e hai ragione, perchè non
mi sono spiegato bene. In realtà il crc - che ho già implementato
da un altra parte - durante i test che ho fatto, ho visto che se
cambi un byte nello stesso blocco (che poi viene sommato agli altri
per dare il crc finale) ... beh in realtà il crc era sempre lo stesso.
Quindi mi andava a succedere che cambiando 1 e mettendolo a 0
su una riga e mettendo da 0 a 1 sulla riga dopo, potrei ottenere la
stessa somma.
Forse ho sbagliato qualche cosa io nell'implentazione ... o magari
basta ridurgli il numero di byte da sommare per il crc stesso.
Comunque, si il suggerimento è più valido dello "sporcare" il registry.
Andrea

 stessa somma.
Dipende dall'algoritmo che usi... se usi realmente il CRC (codici di
ridondanza ciclica) é veramente MOLTO MOLTO difficile.
Il checksum invece é la somma del valore di tutti i byte che compondono il
tuo file. Il teoria il CRC é più efficente.
Vuoi un'altro consiglio?
Firmalo...
Firma il file con una DLL che ti permetta di avere firme tipo PGP o fatti
una tua implementazione di firma digitale basata sulle API di crittografia
di windows. Le probabilità di avere 2 firme identiche sono praticamente
nulle... Nell'archivio di google trovi parecchi post in merito a PGP e
affini. Se usi questa tecnica e volessi essere gentilissimo alla fine dimmi
che DLL hai usato... :)
                    Ciao
                                                Allanon
-- 
- SPAMKILLER
 L'indirizzo delle risposte é 
itlangv...@michele.sytes.net
 LASCIATE il NOSPAM fa parte dell'indirizzo :-)
  Per superare le impostazioni di protezione antispam scrivete
  nel testo del messaggio la scritta "SPAMKILLER"
Scusate il disturbo, ma non posso più di pubblicità

 gentilissimo alla fine dimmi che DLL hai usato... :)
E magari dillo qui sul NG... saresti ancora più gentilissimo! O:-)

 ha scritto nel messaggio
news:bi7v6b$6acph$1...@ID-61006.news.uni-berlin.de...


Cercavo qualcosa di meno incasinato per un file di configurazione ;)

 che DLL hai usato... :)
Pardon
da quello che mi risulta i dati del percorso del db o di altro si
inseriscono in un
cosiddetto file di configurazione in una cartella o nella stessa cartella
dove è presente l'exe
per poter accedere e modificare in modo semplice e soprattutto immediato.
Costruisco un sistema complesso che mi permette si la sicurezza massima, ma
per modificare il percorso
devo leggere un Kg di pagine. Aggiungiamo la possibilità che il costruttore
si dilegui, con tutte le conseguenze del caso.
Non perdo in flessibilità ?
giuseppeD

 Andrea Moro
--