Gestion de l'accès à un fichier excel vb.net

**clementmarcotte** · 01/10/2015, 17h12

Bonjour,

Envoyé par progami

dans mon cas, les informations nécessaires sont les entées saisies dans la fenêtre de dialogue de l'application.net !!
le classeur visiteur doit contenir normalement que les résultats de la fonction F(E) pour que je puisse les transmettre à l'utilisateur

C'est ce que j'ai dit

Pour info, l'application.net tournera sur des postes qui n'ont pas le droit d'accéder au fichier confidentiel
Et quand vous dites "passe la commande", je vois qu'il y a toujours une liaison entre l'application.net et le classeur confidentiel !!!
donc on revient a notre point départ, l'application tournera sur des postes qui ont le droit d'accès et pas sur les autres ...

Je cherche depuis x temps à résoudre ce problème

Là, cela devient un problème pour le Service de Dictature Informatique. Veut, veut pas, il faut accéder au fichier confidentiel. Sinon, comment veux-tu obtenir un résultat ?

Si tu veux le beurre, l'argent du beurre et les confitures en même temps, tu installes un service de requêtes et tu trouves quelqu'un qui a tous les droits d'accès pour qu'il remplisse lui-même toutes les requêtes et renvoie les résultats.

**mactwist69** · 02/10/2015, 08h49

J'en reviens à la solution la plus simple que j'ai préconisé, à savoir :

Je ne suis pas pro excel, mais je pense qu'il y a surement moyen, dès que le fichier excel est enregistré, d'exporter automatiquement certaine données dans un autre fichier... Ce serait donc une sorte de vue, avec pas de données confidentiel. Et celui-ci serait accessible.

**clementmarcotte** · 02/10/2015, 19h35

Bonjour,

Bon, résumons-nous.

Windows, et probablement tous les logiciels de gestion de réseau, permettent de donner des droits d'accès à des programmes, des dossiers et des fichiers à des personnes ou à des groupes de personnes.

Tu peux voir ces exemple gratuit de MS:

https://code.msdn.microsoft.com/Secu...ample-42facaf1

https://code.msdn.microsoft.com/CCS-...ing-a-9ba05613

https://code.msdn.microsoft.com/User...ation-4b913de9

Pour les presque 2200 exemples VB.net et pas mal plus en C#

https://code.msdn.microsoft.com/site...xt=VB.NET&ac=4

Le chemin "au long":

aller à http://msdn.microsoft.com

Cliquer sur exemples en haut à droite de l'écran.

La dernière solution que j'ai donnée permet d'accéder au classeur confidentiel avec la possibilité qu'il reste invisible (même pas une icône dans la barre des tâches) de l'utilisateur. En t'organisant avec le Service de Dictature informatique, Windows et le Framework, il y a moyen de limiter l'accès au classeur confidentiel en partant, de la gestion du réseau et/ou de ton programme VB.net

Si cela te tente d'expérimenter des solutions qui permettraient de transformer un fichier Excel en exécutable, mais je ne sais pas ce que cela peut donner:

http://www.bing.com/search?q=ex%c3%a...B&PC=NP01&QS=n (Personnellement je ne pense pas que Google soit un meilleur ami que Microsoft.)

D'un autre côté, tu peux toujours réécrire le programme de ton classeur dans ton programme VB.net et afficher ton tableau dans :

Un DatagridView : Permet des solutions x86, anyCPU et x64.

Peut-être dans le contrôle SpreadSheet des Office Web Components. Mais là, je suis à peu près sûr que tu seras limitée à une solution X86 seulement. Ce n'est pas une tragédie tant que Windows va continuer de supporter les applications 32 bits.

Ou bien tu regardes du côté des contrôles SpreadSheet du commerce. Mais là, cela va demander de les acheter.

**clementmarcotte** · 02/10/2015, 19h49

Bonjour,

Envoyé par mactwist69

J'en reviens à la solution la plus simple que j'ai préconisé, à savoir :

Personnellement, cela me semble une solution possible, même que je pense qu'Excel a toujours une fonctionnalité pour créer des vues d'un classeur. Je ne sais pas comment cela marche, ni ce que cela donne, mais rendu-là, cela s'apprend.

Mais, à mon humble avis, tant que celui (celle) qui a inventé le classeur qui doit rester confidentiel ne lâchera pas un peu de lest, c'est peine perdue. Il n'y a aucun moyen d'utiliser un classeur sans y accéder d'une façon ou d'une autre.

**progami** · 05/10/2015, 11h04

Envoyé par clementmarcotte

Bonjour,

La dernière solution que j'ai donnée permet d'accéder au classeur confidentiel avec la possibilité qu'il reste invisible (même pas une icône dans la barre des tâches) de l'utilisateur. En t'organisant avec le Service de Dictature informatique, Windows et le Framework, il y a moyen de limiter l'accès au classeur confidentiel en partant, de la gestion du réseau et/ou de ton programme VB.net

cette phrase m'a encouragé ce matin pour reprendre la main sur mon projet ...

ç fait des jours et des jours que je cherche à résoudre ce problème

peux tu préciser exactement ta dernière solution dont tu parles ??

je vous remercie tous pour votre aide

**clementmarcotte** · 05/10/2015, 19h22

Bonjour,

Regarde le numéro 19; avec un des exemples pour contrôler l'accès, au besoin. Mais, il n'y a surtout rien qui t'oblige à tout coder d'un coup. VB.net c'est un peu comme un jeu de blocs de construction. Il est assez flexible pour permettre une sorte de "construction modulaire". Au lieu de voir un immense problème, prends le temps de le "transformer" en une suite de petits problèmes plus ou moins indépendants. Changes l'éléphant en plusieurs souris, si on peut dire. C'est plus facile de se consacrer sur une ou deux parties à la fois que de tout faire ensemble.

**progami** · 06/10/2015, 09h58

Envoyé par clementmarcotte

Bonjour,

Regarde le numéro 19; avec un des exemples pour contrôler l'accès,.

Oui j'ai pris cette solution en compte , je dois la discuter avec mon chef ...

Par contre , je crois (je ne veux pas dire de n'importe de quoi) que c'est plus pratique de mettre le tableau comme source de données local dans Visual studio , et l'avoir après dans le .Exe !!!

Mais est ce que je vais pouvoir garder la confidentialité du tableau ou pas ???

**DotNetMatt** · 06/10/2015, 10h14

Personnellement je vois cette solution juste comme une pure usine à gaz. Sur le moment c'est peut-être l'option qui parait la plus simple, mais à plus long terme, bonjour les coûts de maintenance et les prises de tête pour les évolutions.

Il vaudrait peut-être mieux essayer de voir avec ton chef pour lancer un réel projet autour de ce sujet, et peut-être se passer de ce fichier Excel au profit d'un entrepôt de données (data warehouse) ou d'une solution codée en VB.NET avec une gestion des permissions digne de ce nom...

Ce sera certes un peu plus long à mettre en place, mais ce sera clean et bien plus simple à maintenir.

**progami** · 06/10/2015, 10h54

Envoyé par DotNetMatt

Personnellement je vois cette solution juste comme une pure usine à gaz. Sur le moment c'est peut-être l'option qui parait la plus simple, mais à plus long terme, bonjour les coûts de maintenance et les prises de tête pour les évolutions..

Oui ,mais c'est ce que mon chef propose ...

Envoyé par DotNetMatt

Il vaudrait peut-être mieux essayer de voir avec ton chef pour lancer un réel projet autour de ce sujet, et peut-être se passer de ce fichier Excel au profit d'un entrepôt de données (data warehouse) ou d'une solution codée en VB.NET avec une gestion des permissions digne de ce nom...

Ce sera certes un peu plus long à mettre en place, mais ce sera clean et bien plus simple à maintenir.

ils ne veulent pas enregistrer les informations dans une autre bd le moment ...

**sinople** · 06/10/2015, 11h05

C'est si compliqué que ça de faire une macro Workbook_AfterSave dans le fichier Excel confidentiel qui fait les actions suivantes :

1. Ouvrir le fichier public
2. Transfert les données de la feuille confidentielle vers la feuille public (soit en faisant un copier-coller(valeur) d'une feuille représentant la vue public, soit en faisant une mise à jour de liens dans le fichier public ou autre bricole selon ton besoin)
3. Sauvegarder et fermer le fichier public.

Ainsi à chaque fois qu'un utilisateur confidentiel utilise le fichier confidentiel, il export la vue vers le fichier public. Le seul cas un peu emmerdant c'est que le fichier public soit ouvert lors de la sauvegarde du fichier confidentiel.

Bien entendu cette solution repose sur deux hypothèses :
1. Le fichier Excel est traité et mis à jour par Excel. Ce n'est pas un "entrepôt de donnée" issu d'un export d'un autre système.
2. Les modifications effectuées par les utilisateurs publics ne sont pas répercutées vers le fichier confidentiel. (Genre des opérateurs qui introduisent des factures et c'est le calcul de la commission qui est confidentiel par exemple).

Mais si ces hypothèses ne sont pas confirmées, faut sérieusement prévoir une remise en question de ton système....

**progami** · 06/10/2015, 13h46

Envoyé par sinople

2. Les modifications effectuées par les utilisateurs publics ne sont pas répercutées vers le fichier confidentiel. (Genre des opérateurs qui introduisent des factures et c'est le calcul de la commission qui est confidentiel par exemple).

Mais si ces hypothèses ne sont pas confirmées, faut sérieusement prévoir une remise en question de ton système....

ce tableau est une feuille de calculs donc l'utilisateur doit l'utiliser pour pouvoir effectuer ces calculs via l'application

donc ton deuxième hypothèses n'est pas confirmées

c'est pour cela je voulais le mette en local dans Visual studio et l'avoir à la fin en .exe , mais je ne suis pas trop convaincue ....

**mactwist69** · 06/10/2015, 14h09

Envoyé par progami

ce tableau est une feuille de calculs donc l'utilisateur doit l'utiliser pour pouvoir effectuer ces calculs via l'application

donc ton deuxième hypothèses n'est pas confirmées

Donc, si on résume, vous avez :

-> Une document Excel confidentiel
-> Mais une parti du document doit pouvoir être lu ET édité par tout le monde...

Donc deux solutions :

1) L'usine à gaz :
Une application à multiple-droits déjà évoquée... ou il va falloir se dépatouiller...
Il faudra aussi pensé que'il va falloir que l'application gère l'accès concurrent au fichier...
Donc une seule personne à la fois pourra ouvrir le fichier en édition...
Cette solution techniquement faisable... Me paraît pas très solide, en plus d'être compliqué

2) faire une VRAI solution :
-> Vous importez vos données Excel dans une base de données (gratuite même)
-> Et une appli avec des profils, comme ça chacun ne vois que ce qu'il à a voir.
-> Plus de problème de droits, plus de problème d'accès concurrent...
-> ET se sera certainement beaucoup plus rapide, et bien plus sûr...

**progami** · 06/10/2015, 14h21

Envoyé par mactwist69

Donc, si on résume, vous avez :

2) faire une VRAI solution :
-> Vous importez vos données Excel dans une base de données (gratuite même)
-> Et une appli avec des profils, comme ça chacun ne vois que ce qu'il à a voir.
-> Plus de problème de droits, plus de problème d'accès concurrent...
-> ET se sera certainement beaucoup plus rapide, et bien plus sûr...

Comme t'as dis c'est une vrai solution , mais ils veulent garder ce tableau excel pour le moment. je suis obligée de respecter cette contrainte !!

**DotNetMatt** · 06/10/2015, 14h30

Avec la solution 2 tu gardes ton fichier Excel. Il y a juste une étape qui consiste à charger le contenu de ce fichier dans la base de données. Et ensuite tu gères tout depuis cette base de données.

**clementmarcotte** · 06/10/2015, 20h56

Bonjour,

Envoyé par DotNetMatt

Personnellement je vois cette solution juste comme une pure usine à gaz.

Plutôt une solution extrême pour contourner la résistance au changement. Cela parait simple en théorie, mais en pratique, je suis moins sûr. Et puis, veut, veut pas, on parle d'interopérabilité du Framework avec des Objets COM. Mais, je me souviens très bien d'avoir dit que c'est loin d'être une solution optimale, surtout en termes de mémoire vive et de ressources. (Quand je dis que ce ne serait pas une mauvaise idée que le "créateur" du classeur lâche un peu de lest.)

Comme on dit par chez-nous : "quand il faut, il faut"

Il vaudrait peut-être mieux essayer de voir avec ton chef pour lancer un réel projet autour de ce sujet, et peut-être se passer de ce fichier Excel au profit d'un entrepôt de données (data warehouse) ou d'une solution codée en VB.NET avec une gestion des permissions digne de ce nom...

J'appuies, surtout que l'on parle (encore) de pousser Excel à la limite.

Ce sera certes un peu plus long à mettre en place

Pas vraiment convaincu que ce serait plus long.

**clementmarcotte** · 06/10/2015, 21h09

Bonjour,

Envoyé par progami

Par contre , je crois (je ne veux pas dire de n'importe de quoi) que c'est plus pratique de mettre le tableau comme source de données local dans Visual studio , et l'avoir après dans le .Exe !!!

Sauf que dès que le tableau est modifié, tu dois tout recommencer.

Mais est ce que je vais pouvoir garder la confidentialité du tableau ou pas ???

Oui, on peut "cacher" une opération avec OLE

Envoyé par progami

Comme t'as dis c'est une vrai solution , mais ils veulent garder ce tableau excel pour le moment. je suis obligée de respecter cette contrainte !!

Alors, prends les grands moyens, et fais leur lire ce fil. C'est probablement le seul espoir de leur faire comprendre qu'ils tentent le diable.

Mais, comme je t'ai dit ailleurs, le plus simple c'est probablement de mettre une personne responsable de ton fichier confidentiel et de lui laisser le trouble des opérations.

**mactwist69** · 07/10/2015, 08h55

Envoyé par clementmarcotte

Alors, prends les grands moyens, et fais leur lire ce fil. C'est probablement le seul espoir de leur faire comprendre qu'ils tentent le diable.

Sans forcement aller jusqu'à les amener sur le forum en réunion, lol...

Si tu es la référente technique du projet, et qu'on te demande de plancher sur un sujet et que tu sais que quelque chose ne va pas :
c'est à toi de récupérer toutes les infos et de proposer plusieurs solutions, et pour chacune d'elle dénombrer les points forts et faible.

Si pour la solution qu'ils préconisent, il y a dans point fort : "On garde le fichier excel" et dans les défauts il y a "Impossible de déterminer la durée du projet car compliqué" + "sécurité dur a assuré" + "maintenance compliqué" + "évolution impossible"....

Et qu'en face tu mets une autre solution : ou il n'y a que a "migrer des infos dans une bdd" en point faible, et tout le reste va bien en point fort "projet fiable, possibilité d'estimer la durée du projet" + "donnée normalisée et cohérent" + "sécurité des informations et des accès" + "possibilité d'évolution du SI"

Ma foi, si après ça ils te disent toujours de faire la solution 1, moi à ta place, je leur dis OK, mais je ne garantie pas le résultat (en délai, en résultat, en sécurité), Je vous aurai prévenu... Si c'est leur choix inflexible, on peut pas non plus lutter indéfiniment, et tu feras ton projet bancale qu'ils auront commandés, ta responsabilité ne sera plus engagée sur le résultat. C'est eux les décideurs.

Par contre c'est à toi de bien présenter les différentes solutions à la base et être sur qu'ils comprennent.