Version imprimable
Bonjour,
j'ai un fichier Excel enregistré sur le réseau de l'entreprise , il est accessible que par mon équipe,
j'ai développé une application afin d'interroger ce tableau
le problème est que l'application ne fonctionne pas sur les machines qui n'ont pas le droit d'accès au tableau Excel, sachant que l'application tourne déjà sur les autres machines..
Auriez vous une idée pour résoudre ce problème SVP ?
Merci d'avance ;)
Bien heureusement.... Sinon à quoi serviraient les droits sur un réseau ?Citation:
le problème est que l'application ne fonctionne pas sur les machines qui n'ont pas le droit d'accès au tableau Excel
Seule solution : Donner des droits, ou mettre le fichier sur un emplacement que tout le monde peut atteindre, les utilisateurs concernés au moins.
Oui effectivement,
je peux pas donner l'accès que à l'application toute seule :roll: ??
Je ne suis pas sur.... Je ne pense pas en fait.
Sur un domaine, une application utilise les droits de la session utilisateur.
Le plus simple selon moi, c'est de demander à ton admin réseau de mettre le fichier tout seul dans un dossier, et d'accorder les droits à ce dossier à tous les utilisateurs concernés.
Merci pour tes réponses :)
le problème est que ce fichier est confidentiel à l'équipe donc ils ne peuvent pas donner les droits d'accès aux autres ,d'où l'intérêt de l'application !!
Tu vois le souci :(
Vous êtes tous dans "un groupe"... Vous n'avez pas de compte personnel inclu dans un groupe...
Et seul certains devraient pouvoir y accéder, c'est ça ?
Si vous avez tous des comptes personnels, l'admin devraient pouvoir interdire le dossier au groupe, mais l'autoriser pour certains personnelement
oui , chacun a une session
en fait par exemple il y a équipes A B C
les sessions de l'équipe A peuvent y accéder mais les autres session non
et l'application c'est pour permettent aux autres équipes d'interroger ce document sans le voir
C'est pour ça que les bases de données sont pratique...
Cela dis vous pourriez vous en inspirer ! Faire une sorte de vue.
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.
pour la base de donnée, j'ai pensé a basculer vers une bdd local dans visual studio mais c va me faire changer tout le code de l'application
Je n'ai pas compris ce tu veux dire par une sorte de vue , pourrais-tu détailler stp ?
Et bien (je ne suis pas expert Excel), mais j'imagine qu'il est possible de lié deux fichiers excel.
L'un serait le confidentiel, qui dès qu'il s'enregistre, répercute les données "publiques" à utiliser das ton logiciel dans un autre fichier.
Ce second fichier serait une "vue" (terme de base de données, une vue n'est pas une table, mais une requête qui retourne une table... Donc on crois que c'est une table, mais en réalité, c'est juste un reflet de certaine données)
Oui , mais si je fais une requête pour récupérer la table comme étant une vue, je dois certainement liée l'application à ce fichier confidentiel pour récupérer l'image de ce tableau
et alors on tombe dans le mm problème si j'ai bien compris bien sur !!
J'essayer juste d'expliquer le principe d'une vue en BDD... Mais oubli ça.
Moi je parle d'une solution 100% Excel !
Tu as ton Doc1 (confidentiel), l'équipe A peut faire des modifs dessus.
Ce Doc1 est lié à Doc2 dans un autre emplacement réseau.
Quand Doc1 est modifié, les valeurs (non confidentiels) de Doc1 vont aller automatiquement dans le Doc2
Et toutes les équipes ont accès au Doc2 via ton logiciel
Bonjour,
Tout à fait exact. Cela peut varier selon la version d'Excel, mais un classeur Excel peut importer des données d'un autre classeur Excel et même d'Access ou de SQL Server. (Avec OLEDB et même ODBC. Faut peut-être un driver approprié, mais je suppose que cela peut se trouver.)Citation:
Envoyé par mactwist69
Mais Excel, c'est le mouton noir de la classe en matière de sécurité. Dès que l'on parle de confidentialité et de sécurité d'accès, au code VBA ou aux données, il faut oublier Excel pour gérer ces aspects. Les protections intégrées dans Excel conviennent pour se protéger des utilisateurs obéissants et honnêtes, mais ne tiennent vraiment pas contre un individu moyennement compétent ou décidé.
Là, actuellement, c'est le serveur qui "protège" le classeur. Veut, veut pas, s'il veut assurer l'accès aux données à l'extérieur de son groupe et préserver la confidentialité, il va devoir compter sur les possibilités de son réseau et sur l'administrateur du réseau. Cela lui prend un classeur "privé" pour lui et les membres de son groupe qui est patenté pour mettre à jour le classeur "public", où les droits d'accès sont alloués à son groupe et aux "spectateurs" sélectionnés.
Mais, car il y a toujours un mais, Excel n'a jamais été, n'est pas et ne sera jamais un SGBD. Il n'a aucune possibilité sérieuse pour gérer les collisions et les autres erreurs de mise-à-jour.
Je ne suis pas le plus grand expert en SGBD, mais je verrais plus un "entrepôt" de données sécurisé en conséquence avec Access ou SQL Server (d'autant plus que SQL Server Express est gratuit) avec un accès "réglementé" en conséquence.
Aussi non, il y a aussi la possibilité de faire un service WCF tournant sur un serveur qui pourra lire le fameux fichier et que ton application aie interroger ce service au lieu d’accéder directement au fichier. Mais ça devient un peu plus lourd comme système...
C'est sûrement la meilleure solution, par contre un data warehouse avec SQL Server Express je demande à voir niveau performances :aie: Le principal problème étant que l'édition Express a des limitations : un seul processeur physique, 1 GB de RAM et 10 GB d'espace de stockage. Après il faut voir de quelle volumétrie on parle, si on est sur un petit projet ca peut passer.Citation:
Envoyé par clementmarcotte
Citation:
Envoyé par clementmarcotte
Salut,
Merci pour ton explication,
pourrais tu m'expliquer ton idée d'un "entrepôt" stp ?
Merci d'avance
Une solution très moche d'un point de vue sécurité est d'utiliser l'impersonisation pour changer le context de sécurité dans ton application. En gros ça te permet de changer l'identité de l'utilisateur en cours temporairement pour effectuer les manipulations nécessaire à l'accès de ton fichier.
http://www.codeproject.com/Articles/...onation-in-NET
Le problème c'est que ça t'obligera à stocker le couple utilisateur/mot de passe confidentiel en clair dans ton application (ou de faire un formulaire de saisie par la personne autorisée à chaque accès). Ce qui pose un certain problème d'un point de vue sécurité car l'information est visible assez facilement en faisant du reverse engineering.
Il est aussi possible de créer une macro dans le fichier Excel confidentiel qui va exporter les données publiques dans un autre fichier Excel publique à chaque sauvegarde du document par exemple. Par contre Excel ne va pas être capable de mettre à jour des liens depuis une source auquel l'utilisateur n'a pas accès, il faut donc que ça soit le fichier/l'utilisateur confidentiel qui pousse la mise à jour du fichier public et non pas l'inverse.
La macro de mise à jour est assez simple. Il suffit d'ouvrir le fichier publique (juste faire attention à bien activer la mise à jour des liens, il me semble qu'il y a un paramètre sur ce point), puis de sauvegarder les deux fichiers.
Ca me semble être une approche plus simple et pragmatique que de commencer à installer SQL Server.
en fait , ce fichier confidentiel contient une fonction F(E) (la confidentialité de ce fichier est liée à la fonction F(E)), celle-ci est utilisée bien sur pour effectuer des calcules,
E représente la saisie de l'utilisateur dans l'application, donc l'utilisateur doit entrer E , et le tableau Excel fait les calcules en fonction de ce E via l'application
Toujours pour résoudre le problème de confidentialité et suivre vos propositions , le nouveau fichier public ne doit pas contenir cette fameuse fonction, du coup l'utilisateur ne pourras plus faire ces calcules via ce doc public vu qu'il ne contient pas la fonction F(E) !!!!!
j'ai une idée mais je ne sais pas si elle est faisable ou pas ,est ce que je peux intégrer ce tableau dans Visual studio et l'avoir dans le .exe final ????????? :roll:
j'espère que j'étais clair !!
Bonjour,
-------
Note préliminaire ajoutée subséquemment
Prenez toute l'histoire du fichier xslb avec un maxi grain de sel. Dans mon enthousiasme ou ma précipitation, je n'ai pas pensé que cela n'empêche pas Excel de l'ouvrir les yeux fermés. r
-------
Là, j'avoue que je pense tout haut et que je n'ai rien essayé, ni vérifié. Dans les nouveaux formats d'Office (depuis Office 2007), il y a le "format" xslb, qui permet d'enregistrer en mode binaire. C'est le format du classeur de macros personnelles et je ne sais absolument pas ce que cela vaut du côté de la sécurité.
L'idée de base serait un programme VB.net qui servirait d'interface, ou "d'isolant" entre le classeur confidentiel, peut-être enregistré au format xslb et/ou bien protégé sur le serveur, et le classeur du "visiteur", si l'on peut dire. Puisque VB.net (ou même C#, et probablement tout logiciel de programmation compatible avec la plate-forme .net) peut piloter Excel par automation de la même manière que Word peut le faire, ce serait, du moins à première vue, assez simple d'utiliser VB.net pour effectuer les opérations sur le classeur confidentiel et ensuite "transmettre" le résultat au classeur du "visiteur". En principe, le "visiteur" n'accéderait directement qu'au programme VB.net, et à son classeur à la fin du processus et non au classeur confidentiel.
En gros:
L'utilisateur lance le programme VB.net.
Le programme VB.net demande et ouvre le classeur du "visiteur" et prend les informations nécessaires.
Ensuite le programme VB.net "passe la commande" au classeur confidentiel et récupère les résultats.
Le programme VB.net écrit les résultats dans le classeur du "visiteur".
Disons que ce ne serait peut-être pas optimal au niveau des performances et de l'utilisation des ressources (OLE automation est généralement gourmand en mémoire et moins rapide que l'accès direct au fichier avec OLEDB), mais c'est peut-être la manière la plus sécuritaire de le faire, surtout pour avoir accès à des macros qui doivent être protégées. Mais ne pas oublier que les outils de protection et de sécurité du serveur seraient probablement plus efficaces que les protections intégrées à Excel.
Pour le format xlsb, voir ici.
P.S. Rendu là, il y a probablement des gens plus connaisseurs que moi; mais, je serais plutôt inquiet de mettre ton tableau dans ton exécutable. C'est une affaire de rien que de remonter au code source (ou presque) d'un exécutable .net qui n'est pas moindrement protégé ou "obfusqué". Il y a plein d'utilitaires, même des gratuits, qui permettent de faire l'opération
dans mon cas, les informations nécessaires sont les entées saisies dans la fenêtre de dialogue de l'application.net !!Citation:
Envoyé par clementmarcotte
le classeur visiteur doit contenir normalement que les résultats de la fonction F(E) pour que je puisse les transmettre à l'utilisateur
Pour info, l'application.net tournera sur des postes qui n'ont pas le droit d'accéder au fichier confidentielCitation:
Envoyé par clementmarcotte
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 ... :roll:
Je cherche depuis x temps à résoudre ce problème :?
Bonjour,
C'est ce que j'ai ditCitation:
Envoyé par progami
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 ?Citation:
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 ... :roll:
Je cherche depuis x temps à résoudre ce problème :?
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.
J'en reviens à la solution la plus simple que j'ai préconisé, à savoir :
Citation:
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.
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.
Bonjour,
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.Citation:
Envoyé par mactwist69
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. :(
cette phrase m'a encouragé ce matin pour reprendre la main sur mon projet ...Citation:
Envoyé par clementmarcotte
ç 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 :calim2:
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.
Oui j'ai pris cette solution en compte , je dois la discuter avec mon chef ...Citation:
Envoyé par clementmarcotte
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 ???
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.
Oui ,mais c'est ce que mon chef propose ...Citation:
Envoyé par DotNetMatt
ils ne veulent pas enregistrer les informations dans une autre bd le moment ...Citation:
Envoyé par DotNetMatt
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....
ce tableau est une feuille de calculs donc l'utilisateur doit l'utiliser pour pouvoir effectuer ces calculs via l'applicationCitation:
Envoyé par sinople
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 ....
Donc, si on résume, vous avez :Citation:
Envoyé par progami
-> 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...
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 !!Citation:
Envoyé par mactwist69
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.
Bonjour,
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.)Citation:
Envoyé par DotNetMatt
Comme on dit par chez-nous : "quand il faut, il faut" :(
J'appuies, surtout que l'on parle (encore) de pousser Excel à la limite.Citation:
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...
Pas vraiment convaincu que ce serait plus long.Citation:
Ce sera certes un peu plus long à mettre en place
Bonjour,
Sauf que dès que le tableau est modifié, tu dois tout recommencer.Citation:
Envoyé par progami
Oui, on peut "cacher" une opération avec OLECitation:
Mais est ce que je vais pouvoir garder la confidentialité du tableau ou pas ???
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.Citation:
Envoyé par progami
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.
Sans forcement aller jusqu'à les amener sur le forum en réunion, lol...Citation:
Envoyé par clementmarcotte
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.
Merci beaucoup,
je vous tiendrai au courant au cas où il y'aura des nouvelles
Bonjour,
Mais non, juste à changer la page d'accueil des navigateurs Internet. :lol:Citation:
Envoyé par mactwist69
Bonjour,
De retour sur cette discussion :)
pour résoudre ce problème je vais faire le calcule en dehors du fichier Excel et je garde dans ce dernier que les info non confidentiel ;)
merci pour tous