|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Accueil → WINDEV 2024 → Lancer un programme avec les droits administrateur depuis une appli Windev |
| Lancer un programme avec les droits administrateur depuis une appli Windev |
| Débuté par Paul, 16 juil. 2013 16:18 - 15 réponses |
| |
| | | |
|
| |
Posté le 16 juillet 2013 - 16:18 |
Bonjour à tous,
J'ai besoin de créer mon propre updater pour un de mes logiciels fait sous Windev. J'ai fait un petit programme séparé qui télécharge et remplace les fichiers à mettre à jour. Au lancement du programme principal si une nouvelle mise à jour est détectée il lance l'updater avec la fonction LanceAppli() et se ferme pour pouvoir être mis à jour.
Ca fonctionne très bien sauf qu'avec l'UAC il faut que l'updater ait les droits administrateur pour faire tout ça et qu'avec la fonction LanceAppli() le programme d'origine doit avoir des droits supérieurs ou égaux au programme à lancer, impossible de simplement demander une confirmation à l'utilisateur, et bien sûr je ne peux pas demander de donner systématiquement les droits administrateur au programme principal.
Donc, quelqu'un a t-il une autre solution pour lancer l'updater avec des droits admin qu'avec LanceAppli() ? Ou n'importe quelle idée qui pourrait me sortir de cette impasse ? |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
351 messages
Popularité : +75 (75 votes) |
|
Posté le 16 juillet 2013 - 23:17 |
Bonjour,
Il suffit de faire un manifest demandant les droits d'administration au démarrage mais c'est de loin la plus mauvaise solution (un administrateur ne donnera jamais des droits de ce genre à un utilisateur lambda ... en tout cas chez mes clients j'interdis ce genre de chose).
Le conseil que je peux te donner consiste à utiliser les répertoires locaux de l'utilisateur dans lesquels tu as tous les droits.
Cela veut donc dire que tu installes ton applications par utilisateur et non pas par machine mais cela ne doit pas réellement changer grand chose à ton focntionnement ... (moi je fais déjà comme ça avec mon propre updater)
Si toutefois tu voulais quand même faire une mise à jour dans un répertoire avec ce type de droit, alors met ton programme d'update en service et demande à l'administrateur de l'installer.
--
Bon développement, Patrick [3po.fr] |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
11 messages |
|
Posté le 18 juillet 2013 - 10:12 |
Merci pour cette réponse.
J'avais pensé à faire de l'updater un service mais ça implique une installation séparée du programme principal, ce qui est toujours possible mais qui m'ennui un peu vis à vis des utilisateurs.
Et installer un programme dans les répertoires utilisateurs ce n'est pas très propre non ? D'autant plus que ça demanderai à tous les utilisateurs de désinstaller puis réinstaller l'appli.
Sinon y a t-il un moyen de détecter si le programme a les droits administrateur ? J'ai pas l'impression qu'il y ait de fonction pour ça mais en bidouillant un peu je pense qu'on peut le deviner. Ca permettrait d'utiliser l'updater optimisé pour ceux qui sont sur une vieille version de Windows ou qui ont désactivé l'UAC, et de proposer un fallback propre (sous forme d'un programme d'install à télécharger) pour les autres. |
| |
| |
| | | |
|
| | |
| |
Posté le 18 juillet 2013 - 11:28 |
Bonjour,
J'utilise la fonction LanceAppliAssociée() qui fonctionne très bien pour lancer un install en mode administrateur depuis une application lancé en mode utilisateur. Visiblement c'est un appel aux api ShellExecute. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
351 messages
Popularité : +75 (75 votes) |
|
Posté le 18 juillet 2013 - 13:25 |
Bonjour,
Non une installation pour chaque utilisateur est au contraire un gage de sécurité (d'après moi) et évite de mettre la zizanie sur des sessions n'ayant pas besoin de l'application entre autre. [Voir SysRep() avec paramètre : srAppData pour l'utilisateur et srAppDataCommun pour tous les utilisateurs]
Beaucoup d'applications fonctionnent ainsi, exemple : Google Chrome pour la plus connue.
Toutes mes applications fonctionnent maintenant sur ce modèle, ce qui me permet d'installer mes applications sur n'importe quel ordinateur ou sessions sans aucun droit. L'application est déposée sur le net ou sur le réseau local.
Dans le cas du réseau local, je n'ai aucun installation à faire, le simple fait de lancer l'application depuis le réseau l'installe automatiquement en local, l'accès à la BDD se fait via HyperfileSQL serveur. C'est totalement transparent pour l'utilisateur. Au lancement de l'application ainsi qu'à une fréquence que j'ai défini, je vérifie si il y a une nouvelle version, en cas de mise à jour soit j'avertis l'utilisateur qu'il y a une nouvelle version et lui demande de fermer et relancer l'application ou je force le redémarrage (j'en fais bien plus mais ce serait trop long à expliquer, l'idée est de comprendre le principe).
Dans le cas d'une application sur le net, c'est la même chose pour les mises à jour, il n'y a que pour la première installation où je suis obligé de télécharger mon programme d'installation et de l'exécuter toujours sans avoir besoin de droit ... le reste est également automatique.
Parfois je couple les 2 pour m'éviter des téléchargements à répétition et je déteste me promener avec des clés USB ... donc un lancement à partir du réseau local et des mises à jour à partir du net ... comme ça, je n'ai même pas besoin d'aller sur le serveur de mes clients, je pose l'application sur mon serveur et hop le tour est joué.
Note bien qu'il te faudra faire un programme qui te permet de "restarter" ton application car tu ne peux pas mettre à jour ton application bien sûr quand elle tourne. Mon updater gère aussi les patchs ... mais je ne le fais que quand j'ai des petites modifications sinon je régénéré l'exécutable.
Depuis que je fais ça ... Je n'ai plus d'embêtement de droit, de mise à jour et de quoi que ce soit et j'évite des déplacements.
La mise au point d'un tel système est tout de même délicat et demande quelques connaissances ... je dis ça à la vue de certains posts sur ce forum où je me dis que développer c'est un métier !
Dans tous les cas, il faut se poser la question suivante : ai-je besoin de droit d'administration pour mon application ? Dans 99,9% des cas, la réponse est non !
Et pour répondre à Julien : lorsque tu es en mode Utilisateur, le lancement d'une application en mode Administrateur est soumis à la saisie du login/password d'un administrateur. Sinon cela s'appelle un énorme trou de sécurité ... genre tous les utilisateurs sont aussi administrateur ou si l'UAC a été viré. Dans un contexte professionnel, tu ne verras pas ce genre de chose.
--
Bon développement, Patrick [3po.fr] |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
11 messages |
|
Posté le 18 juillet 2013 - 15:06 |
Bon avant tout, merci mille fois à vous deux.
Je viens de finir mes tests et Julien a raison : je ne l'aurais jamais cru mais avec LanceAppliAssociée() l'UAC demande confirmation à l'utilisateur pour lancer l'updater là où LanceAppli() ne fait rien si le programme principal n'a pas des droits supérieurs. Ca me parait tellement peu logique que je n'avais même pas pensé à essayer mais ça marche !
Bien sûr ça demande d'avoir les droits administrateurs pour faire la mise à jour mais ça c'était déjà le cas avant donc ça ne me pose pas de soucis tant qu'il n'y a pas besoin de les donner systématiquement au programme principal.
Je ne pense pas pouvoir me passer d'installer mon appli dans Program Files à cause du multi-plateforme (Mac et Linux via Wine) mais je ferrais quelques tests et dans tous les cas l'expérience de Patrick est très intéressante.
Je comprend le principe, c'est ingénieux et effectivement ça doit bien fonctionner, mais il me semble que placer l'exécutable d'un programme ailleurs que dans Program Files est contraire aux principes de Windows. D'ailleurs Chrome, comme la majorité des logiciels récents, met bien toutes ses données dans l'AppData mais le programme en lui même est bien dans Program Files (chez moi en tous cas).
Du coup soit j'ai mal compris ta démarche soit j'ai l'impression que c'est ta méthode qui est une faille de sécurité, l'idée de l'UAC c'est justement qu'aucun logiciel ne puisse s'installer sur la machine sans qu'un administrateur ne l'ait authorisée. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
351 messages
Popularité : +75 (75 votes) |
|
Posté le 18 juillet 2013 - 15:39 |
Bonjour,
Pour installer "Chrome" sans droit Administrateur ... il faut au moment de l'installation que tu refuses les droits et tu verras le message suivant :
Après je te laisse en tirer les conclusions qui vont bien avec.
Concernant le test pour les droits "Administrateur" ... aucun problème pour faire cela en 100% Windev.
--
Bon développement, Patrick [3po.fr]Message modifié, 18 juillet 2013 - 15:40 |
| |
| |
| | | |
|
| | |
| |
Posté le 18 juillet 2013 - 16:14 |
LanceAppliAssociée() appel l'api shellExecute alors que LanceAppli() appel l'api CreateProcess qui échoura si le processus demande des droits d'admin.
Plus d'info sur :
http://technet.microsoft.com/fr-fr/library/dd835540(v=ws.10).aspx
@Patrick : Oui cela fonctionne sauf en entreprise (Win serveur) ou on peut empêcher l’exécution de binaire dans les dossiers de l'utilisateur via une GPO. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
11 messages |
|
Posté le 18 juillet 2013 - 16:16 |
Huhu... Ok, je ne savais pas pour Chrome.
Du coup j'imagine qu'il doit exister des limitations pour les programmes installés en dehors des répertoires systèmes, au moins sur l'exécution automatique, autrement l'UAC ne servirait absolument à rien. Mais même si c'est le cas ça ne semble pas être bloquant pour ce qu'on veut faire.
Un grand merci pour l'info en tous cas. Je vais prendre le temps de faire des tests pour voir si ça peut être appliqué à mon logiciel. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
351 messages
Popularité : +75 (75 votes) |
|
Posté le 18 juillet 2013 - 16:59 |
Bonjour,
@Paul : Pas de problème. (pour les restrictions, comme le dit Julien il n'y a que la GPO qui peut bloquer cela sérieusement)
@Julien : oui, c'est une possiblité de la GPO c'est vrai, mais je demande dans ce cas à l'administrateur d'autoriser le lancement de mes exécutables. Il est relativement facile de modifier la stratégie pour ça et de l'appliquer sur 500 postes en quelques secondes et ainsi régler les problèmes de mise à jour comme l'exposait Paul.
Après plusieurs essais chez des clients dans différents contextes, cela est pour moi une des solutions la plus efficace surtout quand on voit la galère des mises à jour. Le tout couplé avec la modification de la BDD Hyperfile à chaud ... et c'est un énorme temps de gagné ! Depuis longtemps, je ne me soucis plus des mises à jour et des installations sur les nouveaux postes.
Sinon je fais également des updates via un service quand je rencontre un client qui désire l'application dans "Program Files" ou si je n'ai pas la possilbité d'utiliser "AppData" ... au même titre que "FireFox" par exemple, Dans ce cas, je dois bien sûr faire une installation du service avec les droits 'Administrateur".
Je pense qu'il est difficile de trouver une solution unique et idéale et c'est le client final qui va déterminer la solution ou les solutions possibles et c'est surtout en fonction de l'administrateur réseau ... certain étant réfractaire à pas mal de chose !
Néanmoins je suis toujours prêt à tester d'autres solutions et tout retour d'expérience est bon.
--
Bon développement, Patrick [3po.fr]Message modifié, 18 juillet 2013 - 17:06 |
| |
| |
| | | |
|
| | |
| |
Posté le 18 juillet 2013 - 17:13 |
@Patrick : Tout à fait. Comment fais tu pour gérer les mises a jour en cas d'utilisateurs multiples sur un même PC ?
C'est pas très économique en cas de mise à jour via Internet... surtout si le réseau n'a pas de cache. Mais comme tu le dis, pas de solution unique. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
11 messages |
|
Posté le 18 juillet 2013 - 18:22 |
@Julien : Je n'avais pas vu ton explication pour LanceAppli() et LanceAppliAssociée(), effectivement du coup ça devient logique mais pour le comprendre il vaut mieux être calé sur les API Windows. L'aide de Windev pourrait être plus précise à ce sujet, surtout qu'ils expliquent bien la limitation au niveau des droits pour LanceAppli().
@Patrick : Sinon je suis d'accord que c'est le client qui va conditionner la meilleure méthode à adopter mais en l'occurence je n'ai pas de client ciblé, mon logiciel est utilisé aussi bien par des entreprises que des particuliers, partout en France et sur toute sorte d'infrastructures, du coup je cherche la méthode la plus souple possible et celle que tu proposes me semble vraiment bien à ce niveau là. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
351 messages
Popularité : +75 (75 votes) |
|
Posté le 18 juillet 2013 - 23:53 |
@Julien : quand la bande passante est critique, c'est l'application sur le réseau local qui se met à jour (via mon service), ce qui permet donc de régler le problème avec les postes locaux. Beaucoup de mes clients travaillent en TSE ... et là c'est encore plus simple et plus rapide puisque c'est une copie directe.
La mise à jour se fait au lancement de l'application donc tant que l'utilisateur n'ouvre pas l'application, il n'a pas de mise à jour. Je n'ai pas cherché à optimiser la mise à jour de toutes les sessions d'un poste d'un coup ... mais tu as raison je vais ajouter ça dans mes TODO (merci pour l'idée) !
J'ai des clients à qui je fais une à deux mises à jour par jour selon les périodes et surtout quand ils ont des grosses demandes et je n'ai pas rencontré réellement de problème de bande passante ... comme cela se passe en tâche de fond (sauf au démarrage où je force la mise à jour) donc si il faut 5 minutes pour charger la mise à jour, ce n'est pas réellement un problème.
Comme je l'ai dit plus haut, avec HyperfileSQL je peux travailler sur des fichiers ayant des évolutions structurelles sans que cela ne gêne les anciennes et les nouvelles versions et ça depuis la version 16 ... c'est le bonheur !
--
Bon développement, Patrick [3po.fr] |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
148 messages
Popularité : +3 (3 votes) |
|
Posté le 30 septembre 2013 - 09:53 |
Patrick ALLÉMOZ a écrit :
Bonjour, Il suffit de faire un manifest demandant les droits d'administration au démarrage mais c'est de loin la plus mauvaise solution (un administrateur ne donnera jamais des droits de ce genre à un utilisateur lambda ... en tout cas chez mes clients j'interdis ce genre de chose). Le conseil que je peux te donner consiste à utiliser les répertoires locaux de l'utilisateur dans lesquels tu as tous les droits. Cela veut donc dire que tu installes ton applications par utilisateur et non pas par machine mais cela ne doit pas réellement changer grand chose à ton focntionnement ... (moi je fais déjà comme ça avec mon propre updater) Si toutefois tu voulais quand même faire une mise à jour dans un répertoire avec ce type de droit, alors met ton programme d'update en service et demande à l'administrateur de l'installer. -- Bon développement, Patrick [3po.fr]
Bonjour
suffirait il d'installer depuis la session de l'utilisateur lambda (sans droit d'admin donc), le programme (avec maj automatique par lan) dans un répertoire propre à sa session comme par exemple dans :
C:\Users\login.DOMAINE\AppData\Roaming\MonProgramme\
pour ne pas etre embeter par UAC lors de la mise à jour du programme (quand il le détecte au lancement)
ps : pour info, mon programme est C/S, n'écrit pas en local, mais peut faire un export excel vers le dossier "MesDocuments" de l'utilisateur |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
14 messages |
|
Posté le 01 décembre 2020 - 07:20 |
Bonjour Patrick,
"avec HyperfileSQL je peux travailler sur des fichiers ayant des évolutions structurelles sans que cela ne gêne les anciennes et les nouvelles versions et ça depuis la version 16"
Pourrais-tu m'expliquer comment créer des structures de HFSQL distinctes pour des versions diferentes d'exe!!!!
--
Olé |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
351 messages
Popularité : +75 (75 votes) |
|
Posté le 01 décembre 2020 - 12:58 |
Bonjour Antonio,
Tu peux faire évoluer la structure de tes données à partir du moment où elle reste compatible avec la description de tes anciennes versions.
Tu peux par exemple ajouter un rubrique sans que cela ne gêne ton ancienne version ... mais tu ne peux pas supprimer une rubrique, tu dois juste ne plus l'utiliser ou mieux la mettre en "Zombie" dans la description de la rubrique.
Voici les restrictions sur la modification structurelle de tes données :
Les structures des fichiers de données doivent être compatibles. Si une des manipulations suivantes est réalisée, les structures sont considérées comme incompatibles :
• Ajout d'une rubrique clé unique (sauf identifiant automatique)
• Passage d'une clé avec doublon en clé unique
• Suppression ou renommage d'une rubrique
• Changement de type d'une rubrique (sauf transformation de texte en texte Unicode)
• Diminution de la taille d'une rubrique
• Diminution de la partie entière ou décimal d'une rubrique de type Numérique
• Une rubrique devient non clé
• Suppression d'un index full-text
• Ajout ou suppression de rubriques dans un index full-text (par contre, la création d'une nouvelle rubrique full-text est compatible)
• Renommer un fichier de données
Espérant t'avoir éclairé sur le sujet ... j'utilise encore aujourd'hui ces techniques d'évolutions structurelles lorsque plusieurs versions peuvent s'exécuter en même temps sinon je modifie réellement la structure.
--
Bon développement, Patrick [3po.fr] |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|