Newsgroup: it.comp.appl.access
Titolo: Relink di tabelle da ACCDE... in esecuzione (con routine di @Alex)

Buongiorno,
sto realizzando un piccolo db da far usare ad alcuni colleghi in rete lan (una decina). In particolare il BE (protetto da psw) risiede in una cartella di rete (di cui nessuno dovrebbe saperne il path), i FE (.accde) saranno distribuiti sulle varie postazioni (tutte con win10 e a2016). Per l'accesso al FE, l'applicativo ha una semplice form di login, dove chiede user e psw. La tabella con le credenziali di tutti i colleghi abilitati risiede nel BE.
 
Mi sono posto il problema della sicurezza ed ho trovato un'eccellente guida di Alex Baraldi (che ringrazio sin d'ora) sulla "creazione" all'apertura delle link table e sulla distruzione delle stesse alla chiusura. Ho creato una tabella di servizio nel BE ed ho "personalizzato" il codice: tutto funziona a meraviglia.
 
Però poi ho pensato: se "qualcuno" tenta di relinkare le tabelle dal FE da altro file accdb, quando il FE è IN ESECUZIONE, cosa succede? Il relink diventa cosa fattibile con pochi e semplici click. Quindi linkando una semplice tabella, questo "qualcuno" può leggere path e password del be. Questo significa avere accesso soprattutto alla tabella con le credenziali d'accesso degli utilizzaziori dell'applicativo.
 
L'unica soluzione che mi viene in mente è quella di spostare la tabella con le credenziali in un secondo BE, protetto con password diversa, ed accedervi dal FE tramite "Set Db = OpenDatabase(...", solo nel momento della verifica dell'utente che chiede di loggarsi all'applicativo. Quindi:
1. l'utente apre il FE (senza alcuna tabella linkata) ed inserisce le sue 
credenziali;
2. il FE, tramite l'opendatabase sul secondo BE, verifica lo user e la psw ed 
eventualmente apre "la prima form", chiude il rs aperto;
3. all'apertura della prima form, relinka tutte le tabelle del primo BE
4. azioni dell'utente
5. chiusura del FE, con distruzione delle linkd table.
 
Resta il fatto che comunque quel "qualcuno" possa ottenere path e psw del BE con i dati... 
 
Premesso che ignoro sicuramente qualcosa, avete suggerimenti? 
 
Grazie
Michele


per individuare la share di rete che "non dovrebbe essere nota" mi pare 
cosa da poco
penso basti avviare il client con il cavo di rete staccato perchè ti 
appaia l'errore con il percorso non trovato.
 
trovata quella, minimo è condivisa in lettura scrittura quindi il be se 
lo possono prelevare facilmente
Almeno nei tempi che usavo access come BE la psw si scardinava con tool 
online grauiti
 
 
per il discorso credenziali spero vengano almeno salvate criptate
 
Suggerimenti? se devi proteggere dati sensibili criptali.
Salvali nel BE criptati
Solo il client in fase di lettura li decripta e li visualizza in chiaro.
Ovviamente è uno sbattimento perchè devi lavorare con form non associate
 
 
BFS
 
 
 
 
 

Scusa ma fatico a capire lo scenario....
Se ti sei al PC con il Fe aperto chi mai potrebbe fare a tua insaputa una cosa simile...?
Quando si abbandonando PC si deve BLOCCARE, non lo si può lasciare di pubblico accesso...
 
Ovviamente questo dovrebbe essere il comporto ds adottare principalmente per tutelare la propria privacy.
 
Detto questo imposta un AUTOLOGOFF oppure manda in protezione il PC  in automatico dopo l'inattività...
 
Mi pare francamente poco sensato dover pensare a questo aspetto sul FE che immagino sia operativo su Utente Autenticato e non preoccuparsi del proprio sistema...
 
@Alex


Per BFS: grazie delle preziose osservazioni... in effetti non avevo pensato di criptare le psw.
 
Per Alex: lo scenario è il seguente: un utente dell'applicativo (che quindi ha ricevuto/installato il FE ed è in possesso di credenziali per accedervi) , che sentendosi smanettone cerca di forzare i blocchi impostati alla ricerca di non so quale buco. 
Presupponendo che dall'ACCDE non si possa tornare all'ACCDB e non trattando dati sensibili, mi basterà criptare il campo Password. 
 
O hai altri consigli per blindare meglio il FE e "nascondere" il BE?
 
Grazie per l'aiuto.
Michele
 
 
 
 

Criptare è un modo discretamente sicuro, quindi puoi salvare nel codice Percorso è Pwd.
Questo ovviamente rende il tutto meno flessibile.
Io salverei in una Chiave di Registro, criptando...
In questo modo con un EXE come INNOSETUP puoi andare a sostituire eventualmente il percorso senza dover sostituire ul FE, che qualche volta contiene personal settings se non si è predisposto un DB locale.
 
Penso sia più che sufficiente per uno smanettone.
 
@Alex

Buona sera.
Ho criptato userid e psw nella tabella nel BE in rete, poichè non posso scrivere nel registro e non posso usare (ahimè) Innosetup. Al momento non prevedo dei settaggi personali da salvare in locale, percui... bene così!
 
Grazie ad entrambi per i preziosissimi consigli!
Michele


Sei sicuro.di non poter scrivere nel Registry...?
Prova a verificare se usando SaveSetting e GetSetting ottieni errori...
Se funzionano, leggi nellanguida dove vanno a scrivere e leggere... e scoprirai che si tratta del registro 😀
Direi che per la tua esigenza sarebbe pou che sufficiente.
 
Leggi questi:
https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/savesetting-statement
 
https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/getsetting-function
 
 
Saluti
@Alex