PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV (précédentes versions) → [WD22] Lancement d'une appli sur serveur
[WD22] Lancement d'une appli sur serveur
Débuté par Ramirez22, 23 déc. 2018 10:20 - 8 réponses
Membre enregistré
60 messages
Popularité : +2 (2 votes)
Posté le 23 décembre 2018 - 10:20
Bonjour,
Le titre étant peu évocateur, je vais développer.
J'ai créé une appli sous Windev 22 pour de la recherche/consultation de fichiers pdf. Cette application interroge un serveur SQL pour obtenir l'emplacement d'un fichier ainsi que les méta données s'y rapportant, puis accède au fichier proprement dit via un serveur de fichier (SMB) pour l'afficher via un ActiveX. Un fichier INI permet de paramétrer l'adresse IP du serveur.

Le serveur physique est sous Windows 2012 R2 et supporte une base postgreSQL + serveur de fichier SMB

Les postes clients sont sous Windows 7 et prochainement Windows 10. Le lancement de l'application se fait en local (chaque poste a son exécutable).

Côté application, tout est fonctionnel : accès à la base SQL et aux fichiers. Les login + mot de passe pour l’accès SMB sont codés "en dur" dans l'application et l'accès à l'appli est assujetti à une connexion à la base SQL.

Hors application, si l'utilisateur essaie de se connecter au serveur SMB (via l'explorateur par exemple), il se heurte à un mur puisqu'il lui faut les ID + MDP (sous réserve qu'il ai récupéré l'IP serveur dans le fichier INI), ce qu'il n'a pas et c'est tant mieux.

Par contre, cela se gâte lorsqu'il essaie de se connecter au serveur de fichier SMB via l'explorateur alors que l'application est ouverte : il peut sans problème accéder à la totalité des fichiers via l'explorateur (limité cependant aux droits sur les fichiers accordés par le serveur en fonction des droits dont il dispose dans l'application... j'espère que vous suivez !).
En gros, comme le "tunnel" est ouvert par l'application vers SMB, l'explorateur peut en profiter pour y aller aussi.

C'est inadmissible, que fait la Police !?!

Bref, vous l'aurez compris, j'aurais besoin d'aide pour trouver une solution pour empêcher l'utilisateur d'aller fourrer son nez dans mes fichiers en dehors de l'application qui lui est gracieusement fournie :) . Plus sérieursement, je voudrais que l'utilisateur avec pouvoir (celui de supprimer les fichiers par exemple) soit obligé de passer par l'application car une suppression de fichier ne se limite pas à effacer le fichier PDF (suppression des méta données, vérification de dépendance etc ...).

J'ai pensé à paramétrer finement SMB, mais je suis loin d'avoir les compétences nécessaires (est-ce d'ailleurs faisable ?).
Aussi, j'ai pensé à déplacer l'exécution de l'application sur le serveur, et de ne faire qu'une interface sur le poste client. Les accès fichiers sont alors inutiles avec le client puisqu'il ne recevra que "l'image". Est-ce que ma démarche est réalisable et si oui, j'aurais besoin d'un peu d'aide parce que je ne vois pas trop comment faire ...

Dici là, joyeux Noël HO HO HO !
Membre enregistré
950 messages
Popularité : +53 (63 votes)
Posté le 23 décembre 2018 - 14:17
Bonjour,

Je sais que c'est du boulot, mais pourquoi ne ferais-tu pas, des webservices pour faire ce que tu souhaites,

Un webservice de listing de fichier avec gestion de sous dossier,
un webservice de telechargement de fichier
un webservice de modification de fichier,

Ca résouderai ton probleme de droit SMB, ce qui te permettrai de fermer ton serveur a tous le monde, tu aurai toi seul les droits.
Posté le 23 décembre 2018 - 19:04
l'adresse IP du serveur aurait pu être cryptée dans le fichier ini
la création d'un sélecteur de fichier personnalisé n'est pas complexe et ainsi ne pas afficher les chemins complets.
Membre enregistré
60 messages
Popularité : +2 (2 votes)
Posté le 23 décembre 2018 - 20:39
Bonsoir,

J'avoue ne pas connaitre les webservices. Je vais me renseigner un peu histoire de ne pas passer Noël dans l'ignorance :D
Membre enregistré
950 messages
Popularité : +53 (63 votes)
Posté le 24 décembre 2018 - 12:55
Il te faudra un serveur d'application ( le serveur gratuit 10 connexions simultanées devrait te suffir) sur ton serveur accessible via le web depuis tes postes clients,

avec windev, tu peux creer un webservice soap, que tu déploiera sur ton serveur, et ton application windev, se connectera aux webservice,

Chaque webservice fera la même que ce que tu fais actuellement , lister des fichier depuis un repertoire mais le fera depuis ton serveur et mais cette fois il renverra un liste via un xml ou json vers ton application et tu devra afficher le resultats,

Cela te permettra d'afficher seulement ce que tu souhaite coté client

Jordan
Posté le 26 décembre 2018 - 09:32
>Par contre, cela se gâte lorsqu'il essaie de se connecter au serveur de fichier SMB via l'explorateur alors que l'application est ouverte

Vous mappez une lettre ?
Sinon pourquoi ne pas utiliser un partage caché avec en plus en mettant un nom de partage bien tordu ?
Membre enregistré
60 messages
Popularité : +2 (2 votes)
Posté le 28 décembre 2018 - 07:50
Bonjour

Jordan, j'ai commencé à regarder pour un webservice et comme vous l'avez signalé, c'est du boulot de reprendre complètement mon application. Je n'ai pas vraiment de deadline pour finaliser ce soft, mais le temps risque de manquer malgré tout. A mes moments perdus, je verrai ce que je peux en faire, mais pour l'instant, je continue sur cette version. Merci de votre proposition.

Thomad, je ne mappe pas de lettre de lecteur. Pouvez-vous m'en dire plus sur le partage caché, je ne vois pas de quoi il s'agit ?

DrCharly93 a écrit :
l'adresse IP du serveur aurait pu être cryptée dans le fichier ini


Ca, c'est une idée à laquelle j'avais pas pensé. Merci, cela va déjà limiter les risques.

J'ai également modifié mon application pour que l'ouverture de la connexion ne se fasse qu'au moment de télécharger le fichier PDF et nom au lancement :
SI RéseauConnecte("", "\\" + gsAdresseIPServeur + "\Plans",ID_connexionSMB ,MDP_connexionSMB) <> 0 ALORS
Erreur("Connexion au serveur de fichiers",ErreurInfo())
RETOUR
FIN
MaFenetreInterne.AX_aperçu>>LoadFile(fichierPDF)
RéseauDéconnecte("\\" + gsAdresseIPServeur + "\Plans")

De cette manière, la connexion est ouverte le temps "juste nécessaire", ce qui va limiter d'avantage les risques.
Est-ce que cette méthode présente des risques auxquels je ne pense pas, puisqu'il va y avoir des ouvertures/fermetures de connexion assez fréquentes (à chaque consultation de fichier) ?

Enfin, je suis en train de voir pour régler l'espace de nom DFS sur mon serveur pour voir si je peux empêcher le parcours du dossier (empêcher l'énumération ...). C'est pas trop mon domaine, mais je pense que cela peut valoir le coup.

Après toutes ces "sécurités", je pense que l'utilisateur lambda aura beaucoup de difficulté à parcourir le répertoire des plans (les fichiers sont de toute manière protégés pas les droits en lecture/écriture). Je ne suis pas complètement à l'abri d'un soft qui historise les connexions pour récupérer l'adresse IP, mais je mets déjà pas mal de barrières. Après, je pense que l'on rentre dans le cadre de la malveillance et c'est un autre sujet.

Si vous avez d'autres pistes, je suis preneur.

Cordialement,
Ramirez
Posté le 28 décembre 2018 - 08:32
Bonjour,

Dans une de mes applis je gère la création de docs, rép. etc... en travaillant uniquement avec un chemin UNC et des params (ip serveur, nom de partage etc...) mis en BDD, genre :

\\IP\NomPartage$

Le $ permet de ne pas voir celui-ci sur le réseau.

Ensuite je joue avec les cdes Windev,, SI fRépertoireExiste, fFichierExiste quand je manipule du rép. (ex: avant suppression d'un rép.) ou pour vérifier que la création du fichier s'est bien passée, enfin du classique.

> je ne mappe pas de lettre de lecteur.
RéseauConnecte, ça y ressemble un peu, non ?

@+

Thomad
Membre enregistré
60 messages
Popularité : +2 (2 votes)
Posté le 28 décembre 2018 - 11:35
Hello Thomad

Thomad a écrit :
Le $ permet de ne pas voir celui-ci sur le réseau.


Je viens il y a 2 minutes de tomber sur cette info, en cherchant sur le net. Merci :merci:

Cela ne fonctionne que sur les OS microsoft, mais comme il n'y a que ça sur notre RLE, ça limite les soucis. Le reste est géré par les autorisations d'accès.
Message modifié, 28 décembre 2018 - 11:36