2016 Architectures Applicatives SERVEUR D’APPLICATIONS TOMCAT OLIVIER D. Table des matières 1 Etat des lieux .......................................................................................................................................... 4 2 Le serveur d’application Tomcat - Introduction ................................................................................... 9 3 Du programme à la configuration du serveur ....................................................................................10 4 L’élément <valve> (logs, restrictions, …) ............................................................................................14 5 Les ressources mises à disposition pour les applications Java ........................................................16 6 La sécurité du serveur et des applications ........................................................................................18 7 Les fichiers journaux – Analyse et supervision ..................................................................................23 Olivier DEHECQ – http://aide.informatique1.fr Page 2 Signalétique Nota, astuce : Contient une partie serveur web qui traite les réponses statiques. Important, à retenir : Ceci est une chose importante Commande MS-DOS C:\> c:\tomcat5.5\bin\startup.bat Commande UNIX # /tomcat5.5/bin/startup.sh Chemin de fichier, dossier, emplacement sur le disque Fichier web.xml Exemple de contenu de document <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" /> Contenu du fichier web.xml <welcome-file>index.html</welcome-file> Contenu du fichier server.xml port "8080" port d’écoute du connecteur Autre contenu de fichier : <role rolename="RUserHelloWorld"/> Spécifique aux documents xml : Balise Nom de propriété Valeur Commentaire Olivier DEHECQ – http://aide.informatique1.fr Page 3 1 Etat des lieux Notion de couches Si une machine fait le tout : Si 2 machines font le tout : Si 3 machines font le tout : 1.1 Les types d’architectures 1.1.1 Architecture 1 tiers 1.1.2 Architecture 1 tiers déployée architecture 1 tiers architecture 2 tiers architecture 3 tiers Olivier DEHECQ – http://aide.informatique1.fr Page 4 1.1.3 Architecture 2 tiers : client / serveur Gestion distante des données : Présentation distante : La base du dialogue : Le middleware prend en charge le protocole de communication client / serveur (1) Service à l’écoute des demandes extérieures (2) Détient les informations sur le serveur à contacter (3) Le driver est formaté pour s’adapter au middleware correspondant (SQL Server, Oracle, …) Une API définit les méthodes de communications avec le serveur selon le langage (Java, .Net, etc.). Si on veut changer de SGBD (ex. : SQL server à la place de Oracle), on change juste le driver propre au middleware. Une API est un dictionnaire présent physiquement dans l’application (en fait partie). 1.1.4 Architecture 3 tiers On s’appuie sur les technologies de la norme W3C car la plupart des postes disposent de navigateurs web prenant en compte HTML, XHTML, CSS et JavaScript. Pas d’installation pour les pc : ce sont donc des clients légers. Olivier DEHECQ – http://aide.informatique1.fr Page 5 La partie développement est déportée sur le serveur d’application (plus facile). 1.1.5 Architecture n tiers Fonctionnement des architecture N-Tiers 1.2 Les rôles Serveur web : Machine qui reçoit les requêtes HTTP. Peut faire serveur de fichiers pour les pages statiques. Serveur d’application : Prend en charge les traitements (construction d’une réponse dynamique). Contient un composant prenant en charge l’exécution du traitement. Contient une partie serveur web qui traite les réponses statiques. Serveur d’objets : Traitements métiers (exemple application orientée objets) / services web (exemple Google Maps®) mis à disposition du serveur d’application pour simplifier la tâche. Exemple de serveurs d’objets : serveur EJB, Microsoft DCOM, CORBA … 1.2.1 Cas de Google Search C’est le développeur du service publié qui crée le fichier WSDL. Le site http://webserviceX.net référence les services publiés. Olivier DEHECQ – http://aide.informatique1.fr Page 6 1.3 Le protocole HTTP A chaque connexion, une nouvelle requête est créée : pas de stockage de résultat (ajouter un serveur BD). URI (Uniform Request Identifier) : http://host:port/path?query#fragment 1.3.1 Types de requêtes http 1.3.2 GET : les paramètres sont dans l’entête de requête POST : les paramètres sont dans le corps de la requête. Utilisation des requêtes Avec un proxy : Lorsqu’il y a un proxy, le proxy renvoie un message 407 (proxy authentication) au client pour lui demander de s’authentifier. Le client répond par un proxy autorization (les identifiants sont transportés dans le corps de la requête : cas d’un POST ; ou dans l’entête de la requête en crypté : cas d’un GET). Le client peut ensuite envoyer les requêtes au serveur web. Autres cas : L’entête des requêtes donne des infos sur le client (langue, navigateur, etc.) et le serveur envoie aussi des informations dans ses entêtes de réponses (durée de cache, durée de session, etc.) Olivier DEHECQ – http://aide.informatique1.fr Page 7 1.3.3 La communication HTTP 1.0 : 1 site par adresse IP Etablissement TCP à chaque requête (350ko) puis libération TCP HTTP 1.1 : X sites par adresse IP : o notion de répertoire virtuel Etablissement TCP à la première demande, libération TCP lorsqu’on quitte le site : o notion de session (espace réservé sur le serveur d’application pour un client donné). Le sessionID : Avec les cookies (1) Le SessionID est généré par le serveur et est unique pour le serveur. Le navigateur doit accepter les cookies Sans les cookies Il est possible de rajouter un champ caché sur la page ou bien de faire de la réécriture d’URL (changer les href), mais la sécurité est moindre car les paramètres sont passés sans l’entête de requête. Olivier DEHECQ – http://aide.informatique1.fr Page 8 2 Le serveur d’application Tomcat - Introduction Utilise la norme J2EE ; langage Java Adresses utiles : Tomcat : http://tomcap.apache.org JRE : http://java.sun.com/j2se 2.1 Installation du serveur d’application Tomcat 2.1.1 Installer JRE et JDK Installer la VM java - le JDK : contient le JRE (java runtime environment) Définir la position de la VM Java : PATH = … ; c:\Program Files\Java\jdk1.6.0_04\bin Définir la position du JDK : JAVA_HOME = C:\Program Files\Java\jdk1.6.0_04 Tester : C:\> java -version Doit renvoyer la version de la VM Java 2.1.2 Installer le serveur Tomcat (à partir du fichier .zip) C:\> netstat -an Pour voir les ports utilisés (8080 doit être disponible notamment, sinon résoudre le problème. Ne pas mettre de caractères spéciaux dans le chemin d’accès à Tomcat CATALINA_HOME = C:\Tomcat5.5 chemin d’installation de Tomcat Il faut fermer et rouvrir l’invite de commande pour que les variables soient prises en compte. C:\> c:\tomcat5.5\bin\startup.bat Démarrage du serveur Tomcat Tester: Ouvrir le navigateur web, URL : http://localhost:8080. Doit afficher la page d’accueil Tomcat. Créer un service windows pour Tomcat : C:\> c:\tomcat5.5\bin\service.bat install Configurer ensuite le démarrage automatique du service. Olivier DEHECQ – http://aide.informatique1.fr Page 9 3 Du programme à la configuration du serveur 3.1 Contenu d’une application web respectant la norme JEE Méthode de fonctionnement des pages dynamiques Méthode de traitement des données 3.2 Structure d’une application Java Répertoire racine (contexte) : WEB-INF Classes Lib racine de la partie privée du site (seulement accessible par Tomcat) servlet - caché par défaut (.class) Références aux composants supplémentaires (.jar) Le reste est dans la partie publique (accessible aussi par le client) : pages .html pages .jsp images, sons, vidéos Olivier DEHECQ – http://aide.informatique1.fr Page 10 Il y a aussi un fichier web.xml descripteur de déploiement : description des traitements Utilisé par le serveur Tomcat pour savoir où se trouvent ses composants 3.2.1 Le fichier web.xml (structure globale) <!--Nom de l’application : --> <display-name>TDCoursDeploiement</display-name> <!--Balises de définition des pages d’accueil du site (dans l’ordre) - Obligatoire : --> <welcome-file-list> <welcome-file>index.html</welcome-file> <welcome-file>index.htm</welcome-file> <welcome-file>index.jsp</welcome-file> <welcome-file>default.html</welcome-file> <welcome-file>default.htm</welcome-file> <welcome-file>default.jsp</welcome-file> </welcome-file-list> <!--Définition des servlets – nom des pages, définissent les actions du programme à mener : --> <servlet> <description/> <display-name>FormulaireServlet</display-name> <servlet-name>FormulaireServlet</servlet-name> <servlet-class>actions.FormulaireServlet</servlet-class> </servlet> <!--Paramètre d’initialisation des servlets – appellent les pages : --> <servlet-mapping> <servlet-name>FormulaireServlet</servlet-name> <url-pattern>/FormulaireServlet</url-pattern> </servlet-mapping> 3.2.2 Le développeur fournit Soit l’arborescence complète : partie publique + partie privée (WEB-INF) dans un seul répertoire, soit un fichier .war (archive compressée de l’arborescence). Olivier DEHECQ – http://aide.informatique1.fr Page 11 3.3 Déploiement sur un serveur J2E Le fichier server.xml est structuré selon l’organisation présentée dans le schéma : _ Server (1 seul) |_ Service (de 1 à n services) |_ Connecter (de 1 à n connecteurs) | _ Engine (1 seul) |_ Host (de 1 à n hosts) |_ Context (de 0 à n contexts) Pour savoir quelle sera la page par défaut d’un site : web.xml Pour configurer le server : server.xml 3.4 Arborescence Tomcat \ bin exécutables \ common répertoire partagé entre le serveur et les applications \ classes fichiers .class \ lib fichiers .jar \ conf server.xml toute la configuration de l’instance du serveur Tomcat tomcat-users.xml définit les droits des utilisateurs \ logs catalina-.log démarrages et arrêts détaillés du service stderr/stdout erreurs et sorties des applications Java prévues pour \ webapps répertoire de dépôt des applications \ ROOT page par défaut de Tomcat \ work contient les fichiers générés par les requêtes 3.5 Le fichier server.xml Règles d’écritures : Ecrire tout en minuscule (sauf contre-indications) Pas de caractères spéciaux (à cause d’UTF-8) Attention à la case des composants Java : java.xyz.Xyz Attention à l’ordre et à la fermeture des balises Faire une copie de sauvegarde avant d’éditer le fichier Aide : http://localhost:8080/tomcat-docs/config/host.html Olivier DEHECQ – http://aide.informatique1.fr Page 12 3.5.1 Les balises Structure des balises xml : <Host name="localhost" appBase="webcoursapps" unpackWARs="true"> </Host> Fichier server.xml : <server> port shutdown <service> name <connector> port secure redirectPort "8443" enableLookup max … min … <host> name appBase unpackWARs autoDeploy "false" workDir <context> docBase path reloadable "true" swallowOutput cookies 3.6 définit les propriétés du serveur "8005" port d’écoute de Tomcat "SHUTDOWN" pour arrêter le service. Il est conseillé de mettre "DODOTOMCAT" définit les propriétés du service "catalina" le changer. Mettre "Tomcat5Service" pour les logs définit les propriétés du connecteur "8080" port d’écoute du connecteur "true" pour les connecteur HTTPS. Connecteur sécurisé redirige les requêtes vers un autre port si il n’est pas capable de les traiter "false" Pour alléger les traitements des serveurs en exploitation définit les performances (découpe le moteur en threads) définit les propriétés de l’hôte "www.monsite.fr" nom de l’hôte. Doit être unique "webcoursapps" sous répertoire de $catalina… contenant ses fichiers "true" pour pouvoir travailler à partir de fichiers .war prend immédiatement en charge changements de fichiers "/work" emplacement du répertoire de travail. /work par défaut. définit les propriétés du contexte (« site web ») "monAppliWeb" répertoire physique contenant le contexte. Emplacement du répertoire de travail, sous-arborescence du dossier de host. "/" ou "/toto" répertoire virtuel du contexte (pour l’appeler en html) prend immédiatement en charge les changements de la partie privée "true" permet la prise en charge des messages dans stdout et stderr (si prévu dans le programme Java). "true" prend en charge les cookies. Vrai par défaut Déploiement d’une application 1. Déployer les webapps : copier les arborescences et les fichiers .war dans le dossier de l’host 2. Vérifier dans les répertoires des arborescences (ou dans le fichier .war), que le fichier web.xml contient bien la page web par défaut : Fichier web.xml 3. Définir le chemin physique et le nom de l’hôte : Fichier server.xml 4. Définir l’emplacement physique et virtuel du contexte (par où on le choppe et où il va réellement chercher les données) : Fichier server.xml 5. Renseigner le fichier hosts : Fichier C:\Windows\Drivers\Etc\Hosts 6. Redémarrer le service Tomcat : C:\> shutdown.bat C:\> startup.bat Olivier DEHECQ – http://aide.informatique1.fr Page 13 4 L’élément <valve> (logs, restrictions, …) Cet élément permet de configurer des traitements qui se lanceront à chaque fois qu’une requête sera exécutée. (Un peu comme un trigger : cf. SQL). Utile pour les logs par exemple. On peut placer la balise <valve> dans <engine>,<host>,<context> ce qui permet de faire de la granularité. Il y a entre 0 et plusieurs valves par balise. On peut associer une valve à un chemin d’accès à une classe Java Exemple de code xml d’une valve : <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> <Valve className="mypkg.MyValve" foo="bar"/> </Host> 4.1 Génération d’un fichier de log local <valve> className "org.apache.catalina.valves.AccessLogValve" définit le rôle de la valve. RemoteAddrValve permet de filtrer les adresses IP. AccessLogValve permet de créer des logs personnalisés. Cas d’une valve AccessLogValve : <Valve className="org.apache.catalina.valves.AccessLogValve" rôle de la valve directory="${catalina.base}/logs" répertoire prefix="access_log" préfixe du nom de fichier log fileDateFormat="yyyy-MM-dd.HH" format de date dans le fichier suffix=".log" suffixe du nom de fichier de log pattern="%t %H cookie:%{SESSIONID}c request:%{SESSIONID}r %m %U %s %q %r" contenu loggé /> 4.2 Génération d’un fichier de log vers une BD <valve className connexionURL driverName tableName /> "org.apache.catalina.valves.JDBCAccessLogValve" permet de logger vers une BD "jdbc:sqlserver://ipaddr:1443;databasename=myDb;user=tomcat;password=t0m" chemin de connexion à la BD. Cas de SQLServer "com.microsoft.sqlserver.jdbc.SQLServerDriver" nom du driver (connexion au MIDDLEWARE de la BD). Cas de SQL Server. "SmaLog" nom de la table qui stockera les données loggées Olivier DEHECQ – http://aide.informatique1.fr Page 14 4.2.1 Côté SGBGR Le port d’attaque du SGBDR est 1443. Un utilisateur tomcat doit être créé avec les droits d’accès. Le formatage de la table est toujours le même pour les fichiers de log. Si on démarre le service Tomcat directement : Erreur grave : exception java.sql.SQLException:com.microsoft.sqlserver.jdbc.SQLServerDriver Il faut copier le driver JDBC pour la base SQL Server : sqljdbc.jar dans \common\lib\ On peut aussi personnaliser les colonnes telles que définies dans la BD si on n'utilise pas le format par défaut. Dans ce cas il faut ajouter des attributs à la balise <valve> (RI p121) 4.3 Les valves RemoteAddrValve et RemoteHostValve (RI p. 121 et 214) Objectif : Restrictions d'accès par adresses IP <Valve> … allow deny "127.0.0.1,10.*" "10.0.2.101" seules ces adresses IP sont acceptées ces adresses IP sont refusées LES RESSOURCES DU SERVEUR <Resource> C'est le développeur qui s'adapte au serveur Olivier DEHECQ – http://aide.informatique1.fr Page 15 5 Les ressources mises à disposition pour les applications Java valeurs constantes (noms prédéfinis) pools de connexion (nom de pool) traitements : classes (noms des traitements) Les noms de ces ressources sont indexés dans l’arbre JNDI. Au niveau de l’application, l’accès à ces ressources et paramétré dans le fichier web.xml : <resource-env-ref> <resource-env-ref-name>envSociete</resource-env-ref-name> <resource-env-ref-type>java.lang.String</resource-env-ref-type> </resource-env-ref> Portée <Context> Visibilité Visible uniquement par l’application <Server> <GlobalNamingResource> Visible uniquement par le serveur Méthode recommandée : <Server> On peut définir directement <Resource> dans le contexte. Méthode Non recommandé ! <GlobalNamingResource> <Resource> <Host> <ResourceLink> 5.1 Mise en place d'une variable (dans server.xml) 5.1.1 Au niveau de la balise <Context> <ResourceLink> name "envSociete" global "GlobalEnvSociete" type "java.lang.String" 5.1.2 nom avec lequel l’appli y accède (tel que référencé dans web.xml). nom de la ressource pour le serveur type de variable (ici : chaîne) Au niveau de la balise <GlobalNamingResource> <Environment> name "GlobalEnvSociete" nom de la ressource pour le serveur type "java.lang.String" type de la variable value "ENI Ecole" valeur de la variable 5.2 Mise en place d’un pool de connexion 5.2.1 Récupérer le driver SQLJDBC.jar (pour SQL Server 2005) Le copier dans \common\lib Le copier dans \server\lib accès pour les applications accès pour le serveur Olivier DEHECQ – http://aide.informatique1.fr Page 16 5.2.2 Définir la ressource ‘pool de connexion’ dans server.xml : <GlobalNamingResource> <Resource> name "PoolSgbd" nom de la ressource (= <ResourceLink global). type "javax.sql.DataSource" pour les pools de connexion auth "container" ou "Application" méthode d’authentification.si « container » alors c’est le serveur qui prend en charge l’authentification, sinon c’est l’application qui le fait (cf. web.xml). 5.2.3 Cas de auth="container" description "BD SQL Server" nom de la ressource pour le serveur (facultatif) driverClassName "com.microsoft.sqlserver.jdbc.SQLServerDriver" nom du driver (connexion au MIDDLEWARE de la BD). Cas de SQL Server. url "jdbc:sqlserver://ipaddr:1443;databasename=myDb;user=tomcat;password=t0m" chemin de connexion à la BD. Cas de SQLServer *username "u1" login, si non défini dans l’url *password "Passw0rd" mot de passe, si non défini dans l’url Caractéristiques du pool : maxActive ["8"] nombre max de connexions simultanées maxIdle ["8"] nombre max de connexions disponibles, en attente minIdle ["0"] nombre min de connexions disponibles, en attente maxWait ["∞"] en ms. Temps max d’attente avant que le serveur renvoie une erreur si elle n’a pas pu être traitée initialSize ["0"] nombre de connexions disponibles au démarrage de tomcat 5.2.4 Au niveau de la balise <Context> <ResourceLink> name "sgbd/sqlserver" global " BD SQL Server " type "javax.sql.DataSource " 5.2.5 nom avec lequel l’appli y accède (tel que référencé dans web.xml). nom de la ressource pour le serveur type de ressource (base de données SQL) Résumé 1) Configurer SQL Server : utilisateur (>Securite>Connexion>sa) + vérifier nom base 2) Copier les fichiers sur le serveur : SQLJDBC.jar 3) Définir server.xml <GlobalNamingResource><Resource> Se baser sur web.xml : <resource-env-ref> <resource-env-ref-name>envSociete</resource-env-ref-name> <resource-env-ref-type>java.lang.String</resource-env-ref-type> </resource-env-ref> <resource-env-ref-name> définit le nom de la ressource 4) Définir server.xml (cf. 2.4.2.4) Olivier DEHECQ – http://aide.informatique1.fr Page 17 6 La sécurité du serveur et des applications 6.1 Présentation globale Objectif : sécuriser l’accès à tout ou partie du site Fichiers intervenant dans la sécurité Olivier DEHECQ – http://aide.informatique1.fr Page 18 6.2 Authentification Basique 6.2.1 Le fichier web.xml Attention à bien fermer les balises au bon endroit ! Le fichier web.xml du serveur est un ‘include’ des fichiers web.xml des applications <!--definir les éléments sécurisés--> <security-constraint> <web-resource-collection> <!--lister les ressources sécurisées--> <web-resource-name>Acces Securisé</web-resource-name> <url-pattern>/FormulaireHttps.jsp</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <!-- activer automatiquement le protocole https pour les urls sécurisées--> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> <auth-constraint> <!--role à définir dans la base de comptes utilisée--> <role-name>RUserHelloWorld</role-name> </auth-constraint> </security-constraint> <!--déclarer le mode d'authentification utilisé--> <login-config> <auth-method>DIGEST</auth-method> <realm-name>ModeDigest</realm-name> </login-config> <!--rôles autorisés pour la connexion--> <security-role> <!--role à définir dans la base de comptes utilisée--> <role-name>RUserHelloWorld</role-name> </security-role> 6.2.2 Le fichier tomcat-users.xml <tomcat-users> <role rolename="RUserHelloWorld"/> <user username="u1" password="secret" roles="RUserHelloWorld"/> </tomcat-users> 6.2.3 Le fichier server.xml On utilise la configuration de base de server.xml. Rien à changer. <GlobalNamingResources> <!-- name=resourceName --> <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" <!-- chemin du royaume --> pathname="conf/tomcat-users.xml" /> … <Engine> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/> Comme le auth-mode du web.xml est BASIC, alors utilise le royaume présent par défaut dans le <Engine>. C’est le UserDatabase, il utilise conf/tomcat-users.xml Olivier DEHECQ – http://aide.informatique1.fr Page 19 6.3 Authentification Digest 6.3.1 Le fichier web.xml Identique à la méthode BASIC, sauf pour les balises : <!--déclarer le mode d'authentification utilisé--> <login-config> <auth-method>DIGEST</auth-method> <realm-name>ModeDigest</realm-name> </login-config> Astuce : la boite de dialogue pour l’authentification est différente ! 6.4 Les royaumes InMemory Realm JDBC Realm royaumes chargés en mémoire. Ex. : tomcat-users.xml royaumes presents sur les Bases de données Olivier DEHECQ – http://aide.informatique1.fr Page 20 6.4.1 Eviter le stockage des mots de passe en clair On peut hacher les mots de passe en SHA ou en MD5 par défaut dans Tomcat (sinon il faut installer des outils). Le mode BASIC permet l’encryptage des mots de passe en SHA et MD5, le mode DIGEST ne prend en charge que le MD5. Méthode (RI p.189) : C:\> digest .bat|.sh -a md5|sha <mot de passe en clair> <mot de passe en clair> : utilisateur:ModeDigest:motdepasse ModeDigest : valeur de <realm-name> dans web.xml 1. Exécuter la commande suivante : C:\> digest.bat -a md5 toto:ModeDigest:1234 2. On copie ensuite le mot de passe haché à la place du mot de passe clair dans le royaume (exemple : tomcat-users.xml) 3. On modifie ensuite la balise Realm de server.xml digest="md5" 6.4.2 Modification du royaume utilisé (pour le mode DIGEST) web.xml : Définir les paramètres souhaités server.xml Placer la balise <Realm> dans le contexte de l’application voulue, changer le resourceName. Dans la balise <GlobalNamingResource><Resource> changer le name et le pathname. dans \conf, créer un royaume et ajouter les rôles et users. 6.5 Résumé sur les ressources et la sécurité <GlobalNamingResource> <Environment <Resource déclaration des ressources ressource simple (exemple : variable) ressource complexe (pool de connexion, user database) <Engine> | <Host> | <Context> mise à disposition pour l’application <ResourceLink lien de la mise à disposition. Ressource de type environment, pool de connexion <Realm lien de la mise à disposition d’un royaume type userDatabase (resource 6.6 SSL (HTTPS) Transport crypté Sécurise le mode de transport (cryptage des requêtes : entête + données), mais le mot de passe + login sont envoyés en méthode BASIC ou DIGEST. 6.6.1 Le fichier web.xml <security-constraint> <!-- activer automatiquement le protocole https pour les urls sécurisées--> <user-data-constraint> < !--au même niveau que la ressource à sécuriser en HTTPS --> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> Il faut en + rajouter les balises permettant le mode BASIC / DIGEST Olivier DEHECQ – http://aide.informatique1.fr Page 21 6.6.2 L’outil keytool (générer un certificat) – RI p.120 C:\> C:\Program Files\Java\jdk1.6.0_04\bin\keytool -genkey -alias <host concerné> -keyalg RSA -keystore <Emplacement du certificat> C:\> keytool -genkey –alias www.helloworld.fr –keyalg RSA –keystore c:\helloworld.keystore Renseigner ensuite tous les champs, sauf le mot de passe de la clé à la fin (à cause de tomcat) 6.6.3 Server.xml <Connector port="8443" disableUploadTimeout="true" acceptCount="100" enableLookups="false" maxSpareThreads="75" minSpareThreads="25" maxThreads="150" maxHttpHeaderSize="8192" keystorePass="password" keystoreFile="c:\helloworld.keystore" sslProtocol="TLS" clientAuth="false" secure="true" scheme="https" /> Fonctionnement de l’envoi de certificat pour https Olivier DEHECQ – http://aide.informatique1.fr Page 22 7 Les fichiers journaux – Analyse et supervision 7.1 Le fichier conf\logging.properties Création d’un handler « 6www_hellowold_fr.org.apache.juli.FileHandler » qui va écrire tout ce qu’il reçoit vers le répertoire de base /logs/www_helloworld_fr-xxxxx.log Création d’un logger « org.apache.catalina.core.ContainerBase.[Catalina].[www.helloworld.fr] » qui va écouter tout ce qui se dit sur le moteur [catalina] pour l’host [www.helloworld.fr] et va le répéter au handler « 6www_hellowold_fr.org.apache.juli.FileHandler » handlers = 1catalina.org.apache.juli.FileHandler, …, 6www_helloworld_fr.org.apache.juli.FileHandler .handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler ############################################################ 1catalina.org.apache.juli.FileHandler.level = FINE 1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs 1catalina.org.apache.juli.FileHandler.prefix = catalina. ##handler personnalisé vers la sortie www_helloworld_fr-xxxx.log 6www_helloworld_fr.org.apache.juli.FileHandler.level=ALL 6www_helloworld_fr.org.apache.juli.FileHandler.formatter=java.util.logging.SimpleFormatter 6www_helloworld_fr.org.apache.juli.FileHandler.directory=${catalina.base}/logs 6www_helloworld_fr.org.apache.juli.FileHandler.prefix=www_helloworld_fr6www_helloworld_fr.org.apache.juli.FileHandler.suffix=.log ############################################################ org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler ##créer le logger pour le host www.helloworld.fr org.apache.catalina.core.ContainerBase.[Catalina].[www.helloworld.fr].level=ALL org.apache.catalina.core.ContainerBase.[Catalina].[www.helloworld.fr].handlers=6www_helloworld_fr.org.apach e.juli.FileHandler org.apache.catalina.core.ContainerBase chemin jusqu’au Server [Catalina] nom du Engine [www.helloworld.fr] nom du Host (en dernier, donc audité) [/context] nom du context (pas dans cet exemple) Créer un handler : Créer un logger (RI p.228) : Lister les handlers : 6www_helloworld_fr.org.apache.juli.FileHandler org.apache.catalina.core.ContainerBase.[Catalina].[www.helloworld.fr] handlers= …, 6www_helloworld_fr.org.apache.juli.FileHandler Récupérer le détail des requêtes (si demandé) dans server.xml (RI p115) : <Host name="www.helloworld.fr" … /> <!--récupérer les requêtes clientes et les écrire dans le fichier de journalisation (cf Logger et Handler dans le fichier logging.properties--> <Valve className="org.apache.catalina.valves.RequestDumperValve"></Valve> Olivier DEHECQ – http://aide.informatique1.fr Page 23