Vulture 2.0.8 : problème d’ordre dans la directive ProxyPass dans le cas de plusieurs applis pour un même FQDN

Depuis la version 2.0.4 de Vulture, il est possible de présenter plusieurs « applications » (comprennez application web) sur un même FQDN, en les différenciant via leur URL complète. C’est notamment utile dans le cas de l’utilisation de PNP intégré à shinken. Vous présentez la webui sur le WAN via https://shinken/, et les graphiques PNP sur https://shinken/pnp4nagios. Vous avez ainsi tout qui fonctionne comme en local dans un seul et même FQDN. Cette mise en place a fait l’objet d’un précédent article : http://zwindler.fr/wordpress/2012/11/17/maj-publier-sur-le-wan-la-webui-de-shinken-via-vulture-2-0-4/ Cependant, en plus d’apporter des fonctionnalités très appréciables, la mise à jour en 2.0.8 a apporté son lots de petits tracas supplémentaires sur mon installation, notament pour Shinken (voir http://zwindler.fr/wordpress/2014/07/25/vulture-2-0-8-des-nouveautes-et-des-impacts-sur-la-webui-de-shinken/) Je n’avais pas encore remarqué immédiatement, mais il y a eu également une regression de Vulture au niveau de la fonctionnalité dont je parle au début. Je ne pouvais plus accéder à mes graphes PNP4nagios dans Shinken. En fait, après avoir analysé les logs, je me suis rendu compte que toutes les requêtes, et en particulier celles pour PNP, était redirigées vers Shinken, provoquant inévitablement un code retour 404 ([Edit]403 en fait[/Edit]). Lire la suite « Vulture 2.0.8 : problème d’ordre dans la directive ProxyPass dans le cas de plusieurs applis pour un même FQDN »

Vulture 2.0.8 : problème d’ordre dans la directive ProxyPass dans le cas de plusieurs applis pour un même FQDN

Quand Vulture 2.0 planne au dessus de la carcasse d’un Lenny et de son fidèle Mediawiki

Peut être que vous connaissez Vulture, mais peut être pas. Pour ceux d’entre  vous qui ne se sont jamais vraiment posé la question de la sécurité pour les contenus web que vous diffusez sur Internet, protéger un minimum ses applications web devient très rapidement vital si elles sont autohébergées, et encore plus (*shock*) si vous les avez développées vous même. On aimerait bien éviter de devenir la porte ouverte à toute les fenêtres…

De plus, une fois la peur des pirates informatique américo-chinois (ou autre gouvernement soutenant ouvertement les pirates informatiques : il n’y a bien que la France pour n’avoir que des équipes de « défense ») étant partiellement écartée, on peut aussi disposer de beaucoup de contenus publiés, disposant chacun de leur propre méthode d’authentification, et souhaiter pouvoir faire du Single Sign On pour éviter d’avoir 50 comptes différents et de taper ses logins/passwords toute la journée! Aaaaah le Single Sign On. Les SSII nous en auront vendu, des solutions clés en mains permettant de s’interfacer avec tout en un clic, ou presque! Toute la nuance étant dans le « ou presque ».

Aujourd’hui, je ne vais donc pas vous vendre la solution ultime à tous vos problématiques de sécurisation de vos applications web ni vous donner un portail SSO universel, mais tout de même… Lire la suite « Quand Vulture 2.0 planne au dessus de la carcasse d’un Lenny et de son fidèle Mediawiki »

Quand Vulture 2.0 planne au dessus de la carcasse d’un Lenny et de son fidèle Mediawiki