Discussion :

[thomine]

Bonjour,

Ca fait un petit moment que je cherche mais il existe plusieurs solutions, je fais appel aux connaisseurs.

J'ai fait une belle appli web en utilisant l'arborescence par défaut, en gros :


├───web
│ tous mes fichiers html, js, css, JSP...
├───WEB-INF
│ ├───classes
│ ├───lib
│ └───src
└───work
build.xml
build.properties

Je cherche à empêcher l'accès direct à work, WEB-INF, et surtout build.properties qui contient des données précieuses sur mon appli.
Je voudrais que seules les requêtes vers mes servlets soient acceptées.

COMMENT FAIRE ???

J'ai essayé de bidouiller la configuration de mon VirtualHost Apache en ajoutant des deny from all dans une directive <Directory>, en me disant, je fais interdire l'accès aux répertoires web... mais ça ne marche pas.

J'essaie de jouer sur les paramètres de redirection d'Apache vers Tomcat avec mod_jk et là ça se présente un peu mieux. J'ai donc un truc comme ça dans ma config d'Apache :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
JkUnMount       /mon_appli/*/          worker1
JkMount         /mon_appli/*           worker1

Histoire d'interdire l'accès aux sous-répertoires de mon appli mais ça ne marche pas vraiment. Avant ça m'afficher le contenu du répertoire, maintenant j'ai un forbidden sur le contenu mais si je mets l'url d'un fichier, et bien je peux le voir.

Quel est donc la manière courante de procéder quand on a une appli web avec tomcat et que l'on veut empêcher l'accès aux fichiers ?

J'ai pensé à 2 autres solutions : les fichiers .htaccess, ou bien préfixer toutes mes servlet par le mot Servlet par exemple et dans mes règles de redirection écrire une règle qui autorise /mon_appli/Servlet*.

Je pense que beaucoup ont déjà eu ce soucis et qu'ils ont trouvé la parade.

MERCI POUR VOTRE AIDE !!!

[ZeKiD]

Soit tu mets tout dans le WEB-INF pour cacher par rapport au navigateur, soit tu déplaces ton work.
Normalement tu as quelque chose de ce type :

+ Web Content
++ répertoire , fichier html , jsp etc..
++ WEB-INF
++ lib
++ classes
++ src
tes fichiers build
+ Work

Autres questions pourquoi mettre tes sources dans une application de prod ? C'est bizarre çà ? Tes fichiers sensibles si besoin est doivent être caché dans WEB-INF, ou ailleurs que dans Web Content[/quote]

[thomine]

En fait, j'ai encore mes sources parce que je ne suis pas encore en version de prod et que pour mettre à jour mon serveur plus facilement, j'ai une tache ANT qui met à jour les sources sur mon serveur par CVS et les compile. Après je les enlèverai.

En fait, j'ai réfléchi encore un peu, et il me semble plus logique de gérer la sécurité le plus tôt possible, donc au niveau du serveur Apache. Je vais donc tester de ne rediriger vers Tomcat que les requêtes qui appellent mes Servlet (par un modèle du style /mon_appli/Servlet*. Par contre, pour qu'Apache empêche l'accès au contenu physique de mes fichiers (appel de http://serveur/mon_appli/build.properties), je ne sais pas trop comment m'y prendre sans tout bloquer. Si je mets des fichiers .htaccess pour empêcher l'accès à certains répertoires, lesquels dois-je laisser naviguable étant donné que je n'accès jamais directement à un fichier (puisque c'est Tomcat qui accède à ces fichiers).

Merci

[ZeKiD]

Il suffit simplement que ton serveur Apache ne pointe pas vers le répertoire Web de ton application dans Tomcat.
Et que tu fasses pointer Tomcat vers tes ressources de ton application, que pour ce que tu as vraiment besoin. Comme les images, les Css, les JS et tout ce qui est statique.
C'est mieux comme çà. Pas d'accès direct connu comme çà.

[ego]

Déjà, je ne vois pas pourquoi tu as tous ces fichiers dans ton appli web.
Les build.xxx et autres sources n'ont pas à être présent dans ton appli.
Quand tu développes, tu travaille dans un espace de développement et avec Ant, puisque tu utilises Ant, tu déploies un WAR. Tu peux faire du hot-deploy = ne pas arrêter Tomcat entre 2 déploiement du même WAR et tu peux aussi demander à Tomcat de ne pas "exploser" ton WAR.
Un autre truc est que tu peux mettre tes pages jsp ou html sous le WEB-INF qui n'est pas accessible

[ZeKiD]

tu peux aussi demander à Tomcat de ne pas "exploser" ton WAR.
Un autre truc est que tu peux mettre tes pages jsp ou html sous le WEB-INF qui n'est pas accessible

Tu peux m'expliquer "exploser" ? C'est quoi çà ?
Sinon je suis de ton avis pour les JSP , mais pas vraiment pour les HTML ! L'intérêt pour le HTML j'en vois pas !!

[ego]

Un WAR est un fichier zip. Les serveurs d'applications font parfois un unzip (c'est mon "explose" le WAR) mais tu peux aussi leur demander de conserver la forme zip.

ok pour les html en dehors de WEB-INF (d'autant plus que tu peux avoir à les mettre sous Apache)

[thomine]

Ok, je vais essayer de déployer mon appli sous forme d'un WAR, c'est vrai que c'est ce qui parait le plus simple.

A ce moment, je dis à Apache de rediriger toutes les requêtes de la forme /mon_appli/* vers Tomcat ? Est-ce la bonne façon de procéder ?

Autre question : les performances sont-elles les mêmes entre utiliser un WAR explosé et un WAR qui reste compacté ?

Je vais me regarder un peu cette histoire de hot-deploy et je vous tiens au courant !

Merci pour ces réponses constructives !

[ZeKiD]

Pour la façon évoquée c'est tout à fait çà.
Pour ce qui est des performances pour ma part, je ne sais pas du tout.
Mais de toute façon je pense qu'elle sont les même une fois toutes les JSP compilés.
Cela m'étonnerait que Tomcat les recompile à chaque fois.
Sinon merci à ego pour l'information sur le fait que Tomcat peut ne pas dézipper le WAR, c'est pas mal du tout.
Tout à fait intéressant.

[thomine]

Pour ceux que ça intéresse, pour éviter que Tomcat explose le WAR et qu'il prenne en compte la mise à jour d'un fichier WAR sans arrêter TOMCAT, il faut que la balise Host de server.xml ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<Host name="localhost" appBase="webapps"
       unpackWARs="false" autoDeploy="true" liveDeploy="true">

J'ai modifié ma tâche ANT qui copie mon WAR (qui ne contient que mes classes, mes lib jar et mes jsp, html, js, CSS) dans CATALINA_HOME/webapps. Ainsi, quand je lance ma tâche, ça me met à jour directement mon application puisque Tomcat "se rend compte" que le WAR a été modifié et recharge l'application.

Donc c'est vraiment super pratique !

Par contre, nouvelle petite question : je vais utiliser un pool de connexion qui je configure habituellement dans la balise <Context> de l'appli. En utilisant cette méthode de déploiement, je n'ai plus de balise <Context> (dans server.xml ou dans un fichier propre de conf/Catalina/localhost).

Peut-on utiliser ce système de déploiement automatique d'un fichier WAR en configurant le Context pour, dans mon cas, utiliser un pool de connexion.

MERCI !!!

[thomine]

Pour ceux que ça intéresse, pour éviter que Tomcat explose le WAR et qu'il prenne en compte la mise à jour d'un fichier WAR sans arrêter TOMCAT, il faut que la balise Host de server.xml ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<Host name="localhost" appBase="webapps"
       unpackWARs="false" autoDeploy="true" liveDeploy="true">

J'ai modifié ma tâche ANT qui copie mon WAR (qui ne contient que mes classes, mes lib jar et mes jsp, html, js, CSS) dans CATALINA_HOME/webapps. Ainsi, quand je lance ma tâche, ça me met à jour directement mon application puisque Tomcat "se rend compte" que le WAR a été modifié et recharge l'application.

Donc c'est vraiment super pratique !

Par contre, nouvelle petite question : je vais utiliser un pool de connexion qui je configure habituellement dans la balise <Context> de l'appli. En utilisant cette méthode de déploiement, je n'ai plus de balise <Context> (dans server.xml ou dans un fichier propre de conf/Catalina/localhost).

Peut-on utiliser ce système de déploiement automatique d'un fichier WAR en configurant le Context pour, dans mon cas, utiliser un pool de connexion.

MERCI !!!

[thomine]

Je viens de trouver ça sur ce site pas mal fait du tout :
http://www-igm.univ-mlv.fr/~dr/XPOSE...cat.php?rub=17

Utiliser un fichier de configuration de contexte

Dans le répertoire appBase d'un Host, on peut déposer, outre les WAR ou applications décompactées, des fichiers de configuration de contexte. Ce sont des fichiers XML contenant comme élément de base un Context, et tous les sous-éléments que l'on peut souhaiter. Il s'agit en fait ici de délocaliser les informations de contexte d'une application. Le format est exactement le même que si on configurait ce Context dans le fichier de configuration du serveur. Cela s'avère intéressant, car ces fichiers peuvent être pris en compte (et les applications correspondantes déployées) sans que le serveur redémarre. Alors que toute modification du fichier server.xml nécessite un redémarrage de Tomcat pour être effective.

Donc, si je résume :

1) Je copie mon WAR dans CATALINA_HOME/webapps
2) Je mets un fichier mon_appli.xml dans CATALINA_HOME/webapps

Mon fichier mon_appli.xml :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<Context path="/mon_appli" reloadable="true" docBase="${catalina.home}/webapps" />

Si quelqu'un pouvait me confirmer que mon fichier de contexte (je n'ai pas encore mis le pool de connexion) est correct pour être utiliser avec un WAR non explosé et que je dois bien le placer dans CATALINA_HOME/webapps plutôt que CATALINA_HOME/conf/catalina/localhost...

MERCI !!!

[ego]

le context en dehors du server.xml a la même syntaxe

[thomine]

Oui, je sais, je m'interrogeais juste sur où mettre le fichier mon_appli.xml (qui contient la balise context). A priori, dans CATALINA_HOME/conf/Catalina/locahost il ne le trouve pas mais dans webapps directement à côté du WAR ça a l'air de marcher.

Sinon, le truc que je trouve gênant avec l'usage du WAR et si l'on possède de s fichiers properties pour configurer notre application, on ne peut plus y accéder. Comment procéder alors ?

Merci.

Pour ceux que ça intéresse, un exemple de fichier contenant un context(c'est ce que j'ai fait et ça marche):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<Context path="/mon_appli" reloadable="true" docBase="${catalina.home}/webapps" />

A savoir aussi qu'il n'y a rien à déclarer dans server.xml (pas de include comme pour Apache par exemple).

[ego]

Mais on peut tout à fait mettre des .properties dans le war !! Ils sont alors chargés via le classpath de la webapp. Par défaut le répertoire WEB-INF/classes est dans le classpath d'une webapp. Donc en mettant ton .properties dedans, tu pourras le charger sans problème

[thomine]

Oui, je sais. C'est ce que je fais. Sauf que pour modifier des paramètres de ces .properties, je ne sais pas comment faire une fois qu'ils sont dans un .WAR.

Alors faut-il paramétrer son appli avant de faire le .WAR. Pour moi, l'intérêt d'avoir des fichiers de propriétés et un .WAR, c'est de facilité le déploiement, et donc adapter son appli au serveur sur lequel on déploie l'appli. Si je ne peux plus accéder à mes .properties une fois qu'ils sont dans un WAR, je trouve que le système perd un peu de ses avantages (puisque si l'appli n'est pas compactée, on peut modifier ses .properties).

Sinon, j'ai trouvé comment utiliser un fichier de contexte dans un .WAR. Il faut créer un répertoire META-INF à la racine de son appli et mettre dedans un fichier context.xml qui contient le contexte de notre appli (avec par exemple le paramétrage du pool de connexion Tomcat). Et voilà, c'est aussi simple que ça. Ensuite, on met le war dans webapps de Tomcat et oh magie, Tomcat utilise notre fichier context.xml du répertoire META-INF pour configurer notre appli. Petite remarque importante, dans la balise contexte, l'attribut docBase doit pointer sur le fichier war.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<Context path="/esp_client" reloadable="true" docBase="${catalina.home}/webapps/mon_appli.war">
	<Resource name="jdbc/mon_appli" 
		auth="Container" 
		type="javax.sql.DataSource"
		factory="org.apache.commons.dbcp.BasicDataSourceFactory"
        driverClassName="com.mysql.jdbc.Driver"
		url="jdbc:mysql://localhost/mon_appli?autoReconnect=true"
		username="aaa"
		password="bbb"
		maxActive="20"
		maxIdle="15"
		maxWait="5000"
		validationQuery="select 1"
		removeAbandoned="true"
		removeAbandonedTimeout="300"
		logAbandoned="true"
	/>
</Context>

Voilà, vous pouvez aussi regarder mon post http://www.developpez.net/forums/viewtopic.php?t=324037 où je parle de la configuration d'un pool de connexion avec Tomcat 5.5

[ego]

Mais un war est un zip. Alors rien n'empêche de lire le war avec winzip, winrar ou autre. Tu édites le .properties et quand tu as fini de l'enregistrer et que tu sors de l'éditeur, winzip ou winrar te demande si tu veux réintégrer le .properties.
Sinon, tu peux aussi préparer le war pour ta plate-forme cible et enfin, tu peux toujours mettre des .properties en dehors du war, dans un répertoire référencé dans le classpath system de tomcat et donc chargeable via le principe des classloaders

[thomine]

Bon, un grand merci à ego pour son intense participation à ce sujet que je vais clore. Je pense qu'il y a assez de renseignements pour répondre à la question.

Je vais tâcher de synthétiser un peu tout ça histoire que ce blabla servent à d'autres.

Le sujet concernait la protection des fichiers d'une WEB-APP, sachant qu'il suffisait de l'url pour voir les fichiers qui n'étaient pas dans le répertoire WEB-INF.

J'utilise mod_jk pour rediriger mes requêtes de Apache vers Tomcat.

1) Dans Apache, je n'ai aucun virtual host ou je ne sais quoi qui pointe vers ma WEB-APP mis à part la redirection de mod_jk (un truc du style JkMount /mon_appli/* mon_worker dans le fichier de conf d'Apache).

2) On peut configurer Tomcat pour ne pas exploser les fichiers WAR :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<Host name="localhost" appBase="webapps"
       unpackWARs="false" autoDeploy="true" liveDeploy="true">

Ainsi Tomcat utilise directement le fichier WAR. Si Tomcat décompacte le WAR, il faut savoir que les fichiers EN DEHORS du répertoire WEB-INF sont directement accessibles par leur URL. Il faut donc soit déplacer ces fichiers dans WEB-INF pour la version de prod, soit les mettre ailleurs.

3) Pour ce qui est de la configuration d'une appli (les fameux .properties), soit on explose (ou Tomcat le fait tout seul) le WAR (et dans la balise Context on met mon_appli au lieu de mon_appli.war) et on peut alors modifier les fichiers de configuration.
Sinon, si le WAR n'est pas explosé, il faut paramétrer l'appli pour la plateforme de destination avant de générer le WAR, OU éditer le WAR avec winzip pour le modifier (mais quand comme moi vous avez un serveur Linux en ligne de commande je trouve ça plus chiant), OU encore, truc que je vais essayer, externaliser le .properties en dehors du WAR du moment qu'il est dans un répertoire du classpath.

Voilà, encore merci à tout ceux qui ont contribué à ce sujet.

Dernière petite interrogation. J'utilise un fichier context.xml que je mets dans un répertoire META-INF. Lorsque Tomcat déploie mon .WAR, tout ce passe bien sur Windows, mais sur Linux il me crée un répertoire mon_appli.xml dans Catalina/localhost au lieu d'un fichier mon_appli.xml. Du coup je suis pour le moment obligé de copier le fichier à la main... Si quelqu'un sait pourquoi !