Password ?

C'est plutot comme un verrou sur ta porte, ca n'a rien de blinde, un bo coup d'epaule ou un fin serrurier en vienne a bout rapidement...

ö,ö
\_/

On ecrit "algorithme" et non "algoryyythme" ,c'était juste pour la rectification!
au plaisir d'une rencontre
tchao

Salut,

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'oublie 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"