Discussion :

[progami]

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

[mactwist69]

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

Bien heureusement.... Sinon à quoi serviraient les droits sur un réseau ?

Seule solution : Donner des droits, ou mettre le fichier sur un emplacement que tout le monde peut atteindre, les utilisateurs concernés au moins.

[progami]

Oui effectivement,

je peux pas donner l'accès que à l'application toute seule ??

[mactwist69]

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.

[progami]

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

[mactwist69]

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

[progami]

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

[mactwist69]

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.

[progami]

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 ?

[mactwist69]

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)

[progami]

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 !!

[mactwist69]

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

[clementmarcotte]

Bonjour,

Et bien (je ne suis pas expert Excel), mais j'imagine qu'il est possible de lié deux fichiers excel.

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.)

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.

[Sankasssss]

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...

[DotNetMatt]

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.

C'est sûrement la meilleure solution, par contre un data warehouse avec SQL Server Express je demande à voir niveau performances 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.

[progami]

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.

Salut,

Merci pour ton explication,
pourrais tu m'expliquer ton idée d'un "entrepôt" stp ?

Merci d'avance

[sinople]

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.

[progami]

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 ?????????


j'espère que j'étais clair !!

[clementmarcotte]

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

[progami]

Le programme VB.net demande et ouvre le classeur du "visiteur" et prend les informations nécessaires.

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

Ensuite le programme VB.net "passe la commande" au classeur confidentiel et récupère les résultats.

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