Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

The Mit's Blog

En plus d'intégrer et skier, il sait même écrire !
(Blog de Renaud Comte)

Actualités


  • Ancien MVP SharePoint 8 ans ...
    Des projets .Net, SharePoint 2013 ou Office 365 ??

    Contactez-nous :

Archives

Lancer des applications depuis votre navigateur : il y a des solutions mais …

Mais voila rien n’est vraiment parfait.

Les browsers web sont, par nature, séparés du poste physique qui les exécute. Soit une sorte de quarantaine d’exécution. Ce qui évite que de petits malins s’amusent à coder des pages Web avec du js qui lancent des FORMAT de vos disques C:/ si précieux.

Mais il existe des alternatives, bien souvent la plus connue est de rajouter un activeX qui lui vas permettre l’appel au poste client

Le soucis : bien souvent, l’activeX permet d’executer tout type d’exe sans distinction…
>>> le risque que cet activeX execute une mauvaise ligne de commande est trop grand pour être concevable.

Certes, bien des gens, plein de bonne attention d’ailleurs, ne veulent ce comportement uniquement dans leur intranet pour donner un coté plus “intégré” à leur site portail, plus Corporate Web Desktop.

image

Et ca se comprend bien : imaginez que votre pack office préféré, votre outils ERP préféré ou toutes autres applications métiers soit disponibles dans votre portail et préconfigurées sur la bonne information et le bon écran …

A vrai dire, c’est un peu la quadrature du cercle, l’utopie concrète, les montagnes du nords et j’en passe.

Au cas ou ce besoin de lancer des applications externes est si forte, je peux vous conseiller de jeter un oeil sur ce produit

IntraLaunch (Payant) 
http://www.particlesoftware.com/en/index.html 
>>> IntraLaunch is an ActiveX control for Internet Explorer & Netscape. It's primarily designed for corporate Intranets with Windows based workstations that need to use a web browser to present menus to their end users or employees. It allows web page links to execute anything from applications to associations such as Word or Acrobat PDF documents both locally and across a network without prompts or security warnings.
Demo : http://www.particlesoftware.com/en/portal/sample.html

Pour ceux qui préférez une autre solution plus simple, et surtout plus “gratuite”, il y a

Launch-in-IE
http://www.whirlywiryweb.com/article.asp?id=%2Flaunchinie
>>> A web page can't readily start an application on the client's computer: quite a few webmasters run into this problem.
This article presents the free LaunchinIE ActiveX Control that will enable HTML pages to start whatever application on the client's machine, without security warnings. To ensure security, LaunchinIE needs to be carefully configured client-side; due to this restriction it's only fit for intranet use. At last, web pages can start Word, Excel, or any other corporate application without complaints. Securely.

Ce que j’apprécie dans ce dernier est la possibilité de restreindre réellement l’exécution d’application le tout sous le contrôle de nos chers administrateurs réseaux (et leurs cousins Security Officers).

En effet, cet ActiveX nécessite que le poste client possède dans sa registry, une suite de clé définissant les différents exe et url d’exécution

registry[1]

Ainsi pas de risque que n’importe quel JS ou HRef exécute quelque exe de manière malicieuse.

Bien sur, il s’agit clairement d’un fonctionnement en intranet où vos administrateurs réseaux, grâce aux GPO vont déployer après validation les mises à jours des registry windows sur les machines du domaines

Pratique et assez secure (pour un intranet) non ?

Bon si vraiment vous êtes un peu fou mais pressé et sous IE, il y a toujours la solution du HTA mais la, je vous laisse juge

http://bytes.com/topic/javascript/answers/92803-script-open-dos-command-window-run-exe-client-intranet

Oh dernier point, (hello Julien), si vous êtes utilisateurs FireFox, vous pouvez aussi utiliser External Application Buttons (EAB) ;)

A bientôt

Renaud Comte aka TheMit (Stramit was in Palma la la la)
Member of WygTeam
http://www.wygwam.com

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: mercredi 9 septembre 2009 20:31 par themit
Classé sous : , ,

Commentaires

Jem a dit :

Ca tombe bien, c'est exactement la problématique que je traite en ce moment : depuis un intranet de centralisation des fichiers clients, pouvoir accéder directement au dossier du client consulté dans les diverses applis métiers (client lourd).

Ma première idée à été de penser ActiveX, etc... beaucoup de boulot pour un résultat incertain.

Puis il m'est venu l'idée de passer par des liens.

J'utilise un en tete de protocole perso ainsi qu'une petite appli locale qui reçoit les requêtes et lance en conséquence les applis locales avec les paramètres.

En gros, sur le site on mets un lien : maboite://monappli/?nclient=1

Et ma petite appli qui est configurée au niveau windows pour traiter le protocole maboite:// cherche l'emplacement de monappli sur le poste local et lance donc le process :

C:\Program Files\MaBoite\MonAppli.exe -nclient=1

Ce système est compatible IE et Firefox ainsi que je suppose la plupart des autres navigateurs, ne comporte pas d'alerte de sécurité (à part pour l'enregistrement initial du protocole dans windows) et me semble assez souple pour pouvoir évoluer en fonction des besoins.

Un lien utile : "Registering an Application to a URL Protocol" http://msdn.microsoft.com/en-us/library/aa767914%28VS.85%29.aspx

# septembre 10, 2009 09:12

FREMYCOMPANY a dit :

@Jem: Je trouve que c'est la meilleure solution en effet. La seule chose est qu'il faut veiller à ne pas laisser de trous de sécurités dans les protocols. Exemple, FireFox registrait firefoxurl: pour son usage interne, et utiliser un fomat genre -page:"%1". Le problème est qu'on pouvait mettre comme donner pour %1 un truc comme [[about:home" -executeJS:alert('bang') -page:"]], et hop, c'était le trou de sécurité garanti...

http://secunia.com/advisories/25984/

# septembre 10, 2009 10:46

Jem a dit :

En effet.

Bon je relativise ca dans la mesure ou :

- mes applis sont un peu moins déployées que firefox et donc les hacker ne sont pas prêt de s'intéresser au protocole maboite://

- mon gestionnaire de protocole ne permet pas de lancer une commande windows quelconque mais seulement une des applis qu'il connait

- je n'implémente comme paramètres de ligne de commande de mes applis que des actions de consultation (donc pas de MonAppli.exe -SupprToutesFactures)

Donc normalement le pire bug de sécurité serait qu'un utilisateur puisse en passant directement par URL accéder à une fonction ou à une donnée qui ne lui est normalement pas accessible. A moi de contrôler ça dans mon interprétation de la ligne de commande.

# septembre 10, 2009 11:03

FREMYCOMPANY a dit :

Les hackers sans doute pas, des utilisateurs malicieux, par contre Wink. Mais, comme tu dis, si on ne fait pas n'importe quoi et qu'on est conscient de la possibilité, il ne doit pas y avoir de problème. Encore faut-il en être conscient.

# septembre 10, 2009 18:16
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01