| 6 Ova, le 1 sep 2002 à 16:58:59Bonjour,
Euh ... oui, ça m'interesse ...
Surtout pour protéger le code VBA... (sauf erreur de ma part on doit logiquement pouvoir protéger bcp de choses via VBA, mais comment protéger ensuite le code lui mm ???)
Merci !!!!
Ova
.:: Ki ne teste rien n'a rien ::.. | 9 blux, le 2 sep 2002 à 11:13:35Salut,
tiens en v'là un peu :
On suppose que tu veux 'sécuriser' une appli pour empêcher l'utilisateur lambda de voir les données autrement que par le biais des formulaires et le VBA que tu as créés.
Cette procédure marche sous ACCESS97, je ne l'ai pas testée sur d'autres versions (peut-être les menus seront-ils différents ?)
- Séparer les torchons et les serpillières :
Le code et les formulaires d'un côté, les tables d'un autre (utilisation de l'attachement de table)
Tu mets la base contenant les données sur un serveur en la nommant avec un nom qui n'a rien à voir (liste.mdb, essai.mdb...) et tu lui positionnes un mot de passe.
Tu t'assures que les accès au rép. de ta base sont correctement positionnés (pas de lecture générale, mais plutôt sur un workgroup, si c'est du NT).
- Restreindre l'accès aux objets :
Dans ta base qui contient le code (que j'appellerai maintenant 'appli'), tu appliques les modifs suivantes :
Dans le menu Outils/Démarrage, tu positionnes l'ouverture automatique d'un formulaire au démarrage et tu décoches tout le reste (y compris dans avancé).
Ensuite, tu peux distribuer ton appli sous forme de fichier .MDE (ACCESS 'compilé'...). Pour ce faire, il faut générer le fichier .MDE, tu vas dans Outils/Utilitaires bases de données/Créer un fichier MDE.
Ca fait déjà une limite correcte pour les 'non-initiés'...
Mais on est encore léger, car l'utilisateur peut encore maintenir la touche 'shift' appuyée au démarrage et ainsi 'bypasser' les ouvertures automatiques de formulaires.
- Il faut donc raisonner autrement, i.e mettre les propriétés en dynamique :
J'ai trouvé cette méthode (criticable, mais qui a le mérite d'exister).
Rajouter ce code sur le chargement du formulaire principal (celui qui s'ouvre en premier).
Private Sub Form_Load()
' Création de la propriété 'antishift' si elle n'existe pas
' Sinon mise à FALSE
Dim Db As Database
Dim Prop As Property
Set Db = CurrentDb
On Error Resume Next
Db.Properties("allowbypasskey") = False
If Err = 3270 Then
Set Prop = Db.CreateProperty("allowbypasskey", dbBoolean, False)
Db.Properties.Append Prop
Resume Next
End If
End Sub
Il permet de positionner ce que j'appelle "l'antishift".
Pour éviter de se faire coincer soi-même (ça m'est arrivé ;-)), il faut prévoir une sortie.
J'ai donc créé un évènement sur double-click dans une zone vierge de mon formulaire qui me permet d'enlever cette propriété 'antishift'.
Je fais un double-click quelque part sur mon formulaire, ça affiche une zone de saisie, je valide un mot de passe et je fais exécuter ce code sur la propriété ApresMaj :
Private Sub B_Passwd_AfterUpdate()
' Mise a TRUE de la propriété si mot de passe correct
Dim Db As Database
Dim Prop As Property
Set Db = CurrentDb
If B_Passwd.Value = "monmotdepasse" Then
Db.Properties("allowbypasskey") = True
MsgBox "Application déverrouillée..."
End If
End Sub
Pour accéder au code et faire les modifications utlérieures de l'appli, il ne me reste plus qu'a lancer l'appli (par le fichier .MDB) cliquer sur cete zone invisible, taper le mot de passe pour déverrouiler, quitter l'appli pour y revenir en maintenant shift appuyé.
Une fois les modifs faites, il faut refaire le .MDE et le lancer une fois (bien entendu, lorsque tu créés ton .MDE, il faut que cette propriété soit désactivée sinon...)
TRES-SUPER-HYPER-ULTRA-MAXI-MEGA-IMPORTANT : N'oublies pas de faire des sauvegardes de tes essais successifs, c'est toujours angoissant de se retrouver avec une erreur qu'on ne peut pas corriger car le fichier est verrouillé (la mise ON de l'antishift est passée, mais la mise OFF se plante), et donc qu'on a perdu toutes les modifs de code qu'on a fait jusqu'à présent.
Je ne connais pas non plus de méthode pour faire du MDB depuis un MDE.
Sinon, penses à mettre des mots de passe 'bizarres' (genre l$_4,h), car ça résiste un peu à une analyse de l'appli en hexa (on peut confondre avec du binaire classique...).
Tout ça protège 'un peu' les données dans le cadre d'une utilisation 'courante' dans une entreprise, mais ça n'empêche pas le petit futé de recopier la base pour s'adonner au cracking chez lui (mais c'est autre histoire).
Le cadre professionnel et la loi interdisent cependant bon nombre de choses lors de l'accès à des données (on peut trouver ces infos sur les logs des serveurs, entre autres...).
J'ai cependant trouvé une faille dans ce système et je ne vois pas comment la corriger.
Il y a aussi une autre solution, beaucoup plus lourde celle-là, c'est de crypter des données 'à la volée' par un algorithme que tu écriras en VB et qui sera appelé lors de chaque lecture/écriture, comme ça tu ne te soucieras plus de mettre un mot de passe sur ta base qui contient les données.
Il faudra uniquement protéger le code qui contient l'algorithme.
Si tu veux plus de précisions sur un point...
A+ Blux "Les cons, ça ose tout.
C'est même à ça qu'on les reconnait" | 11 Ova, le 2 sep 2002 à 12:49:17Merci Blux !
Je vais étudier ça de très près ... si j'ai des questions ou des idées, je te dirai. J'en ai quelques unes (des idées !!!) mais que je n'ai pas encore mises en place.
Par contre, comment fais-tu pour protéger spécifiquement ton code VB ? Pour l'instant, à part le bête mot de passe MS, ... je n'ai aucune idée...
En tout cas merci de ton aide (précieuse !) !!! (Euh pour les sauvegardes intermédiaires ... entièrement d'acc ... je me suis faite avoir une fois ... plus moyen de modifier quoique ce soit, plus d'accès à rien ... j'ai perdu 2 heures avant de me souvenir que j'avais une sauvegarde de la veillle... Grrrr ....)
Bonne journée ...
Ova
.:: Ki ne teste rien n'a rien ::.. |
| 12 blux, le 2 sep 2002 à 13:02:33Le code, il est "protégé" par l'utilisation du fichier MDE et l'antishift, vu que les données sont d'un côté (MDB) et les formulaires (avec le code rattaché) sont d'un autre (MDB et MDE dont tu ne distribues que le MDE).
A+ Blux "Les cons, ça ose tout.
C'est même à ça qu'on les reconnait" | 13 Ova, le 16 sep 2002 à 16:20:32Bonjour,
(euh ... c'est la 3ème fois que je fais mon message, j'espère que cette fois il passera !!)
J'ai essayé cette partie du code :
Private Sub Form_Load()
' Création de la propriété 'antishift' si elle n'existe pas
' Sinon mise à FALSE
Dim Db As Database
Dim Prop As Property
Set Db = CurrentDb
On Error Resume Next
Db.Properties("allowbypasskey") = False
If Err = 3270 Then
Set Prop = Db.CreateProperty("allowbypasskey", dbBoolean, False)
Db.Properties.Append Prop
Resume Next
End If
End Sub
.... sur le 1er formulaire qui s'ouvre. J'ai enregistré, quitté l'appli, lancé l'appli, quitté. Puis revenue avec et sans le Shift .... ben j'ai eu la fenetre base de données à chaque fois :-((((
J'ai donc dû loupé quelque chose .... tu m'espik un ti peu ....
Merci !!!
(Par ailleurs, je n'ai toujours rien trouvé pour Word, Excel ... à part le mot de passe de base ....)
Bonne journée ...
Ova
.:: Ki ne teste rien n'a rien ::.. | 24 blux, le 17 sep 2002 à 10:12:00Pas cool :-(
je me serais-je t'il fourvoyé ?
tatitoulu ce que j'ai écrit avant ?
Notamment :
"Dans le menu Outils/Démarrage, tu positionnes l'ouverture automatique d'un formulaire au démarrage et tu décoches tout le reste (y compris dans avancé)."
Dis-moi si ça va mieux après...
paske bon, au boulot, je protège une appli *sensible* avec ça (suivi d'acitivité du personnel.)
A+ Blux "Les cons, ça ose tout.
C'est même à ça qu'on les reconnait" | 25 Ova, le 17 sep 2002 à 12:06:58Bonjour Blux,
Bon, je viens de retenter la chose. Je confirme.
Mon code est un simple copié-collé du tien. (partie 1 ... celle pour l'anti-shift). Logiquement, je devrai plus avoir accès à rien à part le formulaire ACCUEIL. Et plus d'accès à rien d'autre.... Mais j'ai accès à tout ?????
Il est positionné sur un form qui s'appelle ACCUEIL (configuré pour le démarrage).
J'ai vérifié aussi, c'est bien noté comme évènement sur load (dans le form)
J'ai vérifié (je peux aussi faire une copie d'ecran !!!) ... dans le menu démarrage, tout est décoché. Les seules infos disponibles sont le titre de l'appli, et le nom du form de démarrage.
Dans cette fenetre il y a (pour etre sûre de rien oublier ....)
Titre de l'application = "Mon Titre"
Icone de l'appli = (vide)
Barre de Menu = (par défaut)
autoriser les menus complets = décochée
autoriser les menus contextuels = decochée
Utiliser les touches spéciales d'accès = décochée
Afficher formulaire/page = ACCUEIL
Afficher la fenetre de base de données = décochée
Afficher la barre d'etat = décochée
Barre de menu contextuel : (par défaut)
Afficher les barres d'outils intégrées = décochée
Autoriser la modification des barres d'outils = décochée
Par contre je n'ai pas ce que tu appelles 'avancées' ... tu as quoi comme paramètres dedans ??? (z'ont changé la présentation je pense entre 97 et 2000, mais on devrait retrouver à peu près les mm choses....)
Il y a forcément une explication ... un truc qui me manque, mais quoi .....
Pour info, si je mets la seconde partie de ton code (after up date ....) que je lance, et si je mets le mot de passe, il me renvoie une erreur sur la ligne :
Db.Properties("allowbypasskey") = True
=> "erreur d'exécution '3270', propriété non trouvée.
<agacée>Non-trouvée ... non trouvée ... me prend pour une andouille ? on vient de la créer ....Grrrrrr ... y'a 1 truc que je pige pas .....</agacée>
Voilà ... j'en suis là ....
Ova
.:: Ki ne teste rien n'a rien ::.. | 28 Ova, le 17 sep 2002 à 18:24:20Héhéhéééé !!!
J'ai trouvé ... j'ai mis longtemps, mais maintenant ça marche.
Le pb venait bien d'une bibliothèque de références manquante ...
Maintenant ça marche !!
Je savais bien qu'il manquait quelque chose ... héhé !!!!
Ova
.:: Ki ne teste rien n'a rien ::. | 29 blux, le 17 sep 2002 à 21:29:58Ah ben tu vois, quand tu veux !
Dans ma fenêtre "Démarrage", sous les boutons "ok" et "annuler", j'avais un bouton "avancé>>" qui me permet de décocher "utiliser les touches spéciales d'accès..." car dans ACCESS, un appui sur F11 affiche la fenêtre base de données... quel que soit l'endroit où on se trouve...
Peu sécurisant quand on veut en cacher un peu, non ?
C'est quoi ta référence manquante, pour info ?
Sinon, content de t'avoir aidé (même si ça a été un peu tiré par les cheveux...)
A+ Blux "Les cons, ça ose tout.
C'est même à ça qu'on les reconnait" | 30 Ova, le 17 sep 2002 à 21:39:16Il manquait :
Microsoft Visual Basic for Applications extensibility 5.3 et ADO Ext. 2.7 for DLL and Security
Donc, le CreateProperty passait pas ... (normal ...)
Finalement, ça sert d'etre tétue !!!! Et maintenant, j'ai deux jolies fonctions toutes propres qui marchent !!!!
En tout cas merci de ta patience et de ton aide !!!
Bonne soirée,
Ova
.:: Ki ne teste rien n'a rien ::. |
|
|
|
|
|
|
|
|