Sécuriser MySQL : création d’un utilisateur dédié à une base de donnée

Dans l’ensemble de cet article on supposera l’utilisateur MySQL root existant avec le mot de passe: rootPass

Etape 1 : Créer l’utilisateur

Connectez vous en root sur la table appelée « mysql », et tapez la commandes suivantes.

INSERT INTO user(host,user,password) VALUES (‘localhost’,’nom_user’,PASSWORD(‘pass_user’));

Etape 2 : Créer la base de donnée

En root, il suffit d’entrer les commandes CREATE DATABASE nom_database;.
Pour générer les tables, que vous avez déjà probablement crée lors de la phase de développement, je vous conseille d’exporter la structure depuis le SGBD de dev, puis de l’insérer dans le SGBD de production en utilisant:
mysql -u root -prootPass nom_database <votrefichier.sql

Etape 3 : Attribuer les droits : insertion, suppression, et lecture sur l’ensemble de la base

L’attribution des droits s’effectue avec l’usage de la commane GRANT, comme suit:

GRANT SELECT, INSERT, UPDATE ON nom_database.* TO nom_user@’localhost’ ;

Validez l’attribution de ces droits par:
flush privileges;

Références

http://dev.mysql.com/doc/refman/5.0/fr/adding-users.html

Tutoriel GWT : Création d’un service distant

Avec GWT, la construction d’interface graphique est très simple (on instancie un composant, puis on l’attache au conteneur…). Les évenements respectent le pattern Observateur (on déclare un listener, et une péthode est appelée dès que l’évènement en question est effectué sur l’objet écouté).

L’utilisation des requetes AJAX sont moins évidentes, il faut bien comprendre le mécanisme avant de pouvoir créer ses propres échanges clients / serveur. Ces échanges, désignés comme RPC (appels de fonctions distantes). je ne sais pas s’ils sont strictement équivalents à ceux du protocole RPC. Ce qui est sur, c’est que la contruction d’une méthode GWT-RPC sur le serveur qui sera appelée par le client est encadrée par quelques règles qui imposent les bonnes pratiques de programmation.

La création d’un service GWT distant se crée en trois étapes:
– Défintion des interfaces (une synhrone pour la servlet, une asynchrone pour le client AJAX)
– Implémentation du service
– Ecriture de l’appel au service

Définition des interfaces du service GWT

Une interface n’est ni plus ni moins qu’un gabarit pour une méthode, c’est-à-dire qu’aucun comportement n’est écrit, seul les paramètres d’entrée et de sortie sont définis. L’interface est à placer dans le package client. L’interface doit hériter de RemoteService :


public interface MonService extends RemoteService {
String maMethode();
}

L’interface asynchrone est similaire, à part que le retour de la fonction n’est pas direct, mais s’effectue par le biais d’une fonction de callback, via un objet AsyncCallback passé en paramètre de la méthode. Elle se place elle aussi dans le package client, et dispose du même nom suivi du suffixe Async.

public interface GetWordAsync {
void getWord(AsyncCallback callback);
}

L’implémentation

Les implémentations des services sont des servlets spéciales qui décrivent le comportement du service. La servlet hérite de RemoteServiceServlet et implémente l’interface de description du service MonService précédemment créé. Elle ne doit pasêtre placée dans le meme package que le client, mais das un package com.yourcompany.yourproduct.server !

public class MonServiceImpl extends RemoteServiceServlet implements GetWord {

public String[] maMethode() {
String response = new String("réponse de MaMethode");
return(response);
}

}

Il faut ensuite déclarer la servlet dans le fichier Web.xml du serveur afin qu’elle soit prise en compte.

Appel de la méthode

Maintenant que le service RPC est défini, l’appel d’une méthode RPC se fait en trois temps.

1. Instantiation d’un objet Proxy

Cet objet proxy, on peut le voir comme une brique interposée entre le client et le serveur. L’objet est créé à partir de l’interface synchrone.

MonServiceAsync monService = GWT.create(MonService.class);

2. Définition des méthodes de callback:

Deux méthodes doivent être écrites: le cas ou l’appel de méthoode réussit onSucces, et le cas ou l’appel échoue onFailure.Si vous avez bien suivi, ces deux méthodes définissent l’objet de Callback qui définit l’interface asynchrone.

AsyncCallback callback = new AsyncCallback() {
public void onFailure(Throwable caught) {
}
public void onSuccess(String result) {
}
};


3. L’appel de la méthode à proprement parler.

On peut désormais appeler la méthode sur le serveur depuis notre objet proxy:
MonService.maMethode(callback);

On peut regrouper le tout dans une méthode qui sera ppelée depuis la classe client du rojet:

public void initServerCalls(){
if (monService == null) {
monService = GWT.create(MonService.class);
}

AsyncCallback callback = new AsyncCallback() {
public void onFailure(Throwable caught) {
Window.alert("Echec à l'appel du service");
}
public void onSuccess(String result) {
Window.alert(result);
}
};

monService.maMethode(callback);
}

HOWTO: configure Tomcat to send mails, using javamail

This article shows step by step a way to configure Apache Tomcat J2EE server to send emails.

You will need first a working Tomcat server of course, and a mail server. You can have it on your own machine, just like me, so the smtp server would be « localhost », or on another machine from which you can use smtp, for instance your Internet Service Provider smtp (generally smtp.nameofyourISP.com)

Step 1 : Install the right libraries:

Sending mails with tomcat require 2 librairie: the javamail API, and the Java Activation Framework (jaf).
Depending on your JDK /JRE version, you will need to place 1 or 2 files in your /catalina_home/commons/libs/ folder.
If you have a 1.6 java version (check with java -version) you will need only the mail.jar otherwise, you will need both mail.jar and activation.jar.

Important: you must not include these two files into your webapp, or you will get an almost wired error:
java.lang.ClassCastException: javax.mail.Session cannot be cast to javax.mail.Session

Let’s download the files:

javamail-1_4_1.zip

With JDK / JRE 1.6 it’s the only one you will need. With other versions, take also this file: java activation framework

Unzip these file (if needed, on a Debian system for instance, download the zip package: apt-get unzip), and move it to the appropriate catalina folder (don’t forget to stop tomat service before).

mv /home/your_username/javamail-1.4.1/mail.jar /your_tomcat_home/common/lib/

The same applies to the activaction.jar if needed.

2. Configure your webapp:

2 step to configure your webapp. First, edit the conext.xml, and declare you mail ressource to make it available:

<Resource auth="Container" mail.smtp.host="localhost" name="mail/NomDeLaRessource" type="javax.mail.Session"/>

Next, edit your web.xml file and declare your webapp using your mail resource:

<resource-ref>
<description>Votre description </description>
<res-ref-name>mail/NomDeLaRessource</res-ref-name>
<res-type>javax.mail.Session</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

3. Write the code

To test your configuration, here is a working sample code:

Session session = null;
try {
Context initCtx = new InitialContext();
Context envCtx = (Context) initCtx.lookup(« java:comp/env »);
session = (Session) envCtx.lookup(« mail/NomDeLaRessource »);

} catch (Exception ex) {
System.out.println(« lookup error »);
System.out.println( ex.getMessage());
}

Here is the code which actually send the mail:


Message message = new MimeMessage(session);
try {
message.setFrom(new InternetAddress(expediteur);
InternetAddress to[] = new InternetAddress[1];
to[0] = new InternetAddress(destinataire);
message.setRecipients(Message.RecipientType.TO, to);
message.setSubject(sujet);
message.setContent(corps, "text/html;charset=UTF-8");
Transport.send(message);
} catch (AddressException ex) {
System.out.println( ex.getMessage());
} catch (MessagingException ex) {
System.out.println( ex.getMessage());
}


The most convenient is to create a hepler method, with receiver adress, subject, body, etc…but that’s your work 🙂

Thanks goes to tomcat mailing list people, especially Chuck and Martin.

Références : tomcat.apache.org/

Debian: comment activer les logs du démon cron ?

Par défaut sur la Debian, les logs de cron ne sont pas activés;

Si comme moi vous n’avez pas de sortie dans /var/log/crond, il vous faut éditer /etc/syslog.conf et rajouter cette ligne:

cron.* -/var/log/cron

Sauvez et quittez, puis créez le fichier avec touch /var/log/cron.
Redémarrez le démon syslog avec /etc/init.d/sysklogd restart.

Et voilà !

Apache: configurer correctement les vhosts

Un seul serveur web Apache est capable de servir plusieurs sites. Il est possibles de distinguer ces sites différents par leur adresse ip, ou par leur nom de domaine.

Cet article présentera la manière de configurer pour une seule ip / plusieurs sites web désignés par leur nom (l’inverse est aussi possible) grâce aux virtual hosts.

Nous allons d’abord utiliser la directive NameVirtualHost *.80 (on utilise * pour que répondent à la fois l’adresse ip du serveur, et à la boucle locale) pour déclarer que une seule adresse ip peut répondre a plusieurs noms de domaines différents (on parle de « name Based VirtualHost »).

Ensuite, chaque host va être décrit entre des balises

Les directives à connaitre sont:

ServerName
Donnez le nom de domaine auquel le site doit répondre.
DocumentRoot
Donnez le chemin qui contient les données du site

ErrorLog
donnez le chemin du fichier de log des erreurs de ce host

CustomLog
Donnez le chemin du fichier de log dédié aux accès à ce host, suivi du mot clé « combined » sion le démmaraage du service vous donnera une erreur (combined sert a formatter les informations affichées dans le fichier de log)

Spécifier l’adresse et le port auquel doit répondre le vhost?

Il pourrait etre tout a fait intéressant de servir différents sites web sur différents ports:
Il suffit de déclarer

Fichier exemple et notes sur l’organisation:

Il serait possible d’inclure tous ces vhost dans le fichier httpd.conf (cf. article Aprendre à configurer Apache httpd). Sur Debian, la gestion des sites web avec Apache est facilitée par l’organisation des répertoires. Chaque vhost est configuré dans un fichier distinct, placé dans le répertoire /etc/apache2/sites-availables/, puis un lien symbolique est réalisé dans le dossier /sites-enabled/… ca permet en un seul coup de main, et sans devoir supprimer des configurations existantes, d’activer/désactiver des sites à la volée!

Exemble de vhost pour un site:

#configuration du site www.site1.com
<Directory /var/www/site1>
Order Deny,Allow
Allow from All
</Directory>
<VirtualHost *:80>
ServerName www.site1.com
DocumentRoot /var/www/site1
AddDefaultCharset ISO-8859-15
CustomLog /var/log/apache2/site1.access.log combined
ErrorLog /var/log/apache2/site1.errors.log
</VirtualHost>


Je vous souhaite une bonne mise en ligne 😉

HOW-TO : Serveur Tomcat sur Debian, Apache en proxy avec AJP

Je vais tenter de détailler pas à pas l’installation d’un serveur applicatif Tomcat (pour exécuter des servlet donc), conjointement au serveur web Apache avec l’utilisation d’un connecteur AJP proxy.

Apache sera donc en proxy (utile pour les données statiques). On supposera qu’Apache 2.x est déja installé sur la machine (sinon un apt-get install apache2 fera certainement l’affaire, ce n’est pas l’objet de cet article).

Allez, on y va!

Premièrement nous aurons besoin:

– d’une machine virtuelle java

– des binaires du serveur Tomcat

– des binaires du connecteur mod_jk Nous utiliserons mod_proxy, plus récent, plus rapide !

Concernant les versions, un JRE 1.5 (le jdk complet n’est plus obligatoire) et un tomcat 5.5 seront suffisant pour nous. Tomcat 6 n’apporte pas de réelle valeur ajoutée a mes yeux, et la version 5.5 est toujours maintenue.

1. Installation de la JVM:

Pour la télécharger, cette ligne de commande fera l’affaire:
wget http://javadl.sun.com/webapps/download/AutoDL?BundleId=23103 (copiez collez l’adresse récupérée du site de sun pur éviter de recopier l’adresse a la main)
On rend l’archive exécutable avec;
chmod +x ~/jre-6u7-linux…[TAB pour autocompletion]
Puis on se place dans le dossier adéquat pour installer une JVM (pour moi ca sera /opt, hop!), on lit patiemment l’accord de licence, on accepte, et la JVM s’installe.

cd /opt

~/jre-6u7-linux…[TAB pour autocompletion]

On va maintenant définir les variables d’environnement. On ouvre avec vim le fichier /etc/environment et on ajoute la ligne:

JRE_HOME= »/opt/jre1.6.0_07/ »

on peut egalement ajouter :/opt/jre1.6.0_07/bin a la variable PATH…

Testons dans le shell en tapant un petit java -version (après avoir démarré une nouvelle session pour prendre en compte les modifications).

2. Installation de Tomcat

On télécharge l’archive (veillez à bien prendre la dernière version, des mises à jour de sécurité importantes sont effectuées assez régulierement):
wget http://mirror.mkhelif.fr/apache/tomcat/tomcat-5/v5.5.27/bin/apache-tomcat-5.5.27.tar.gz
Se placer dans le répertoire /opt, et taper cette commande pour decompresser l’archive:

tar -zxvf ~/apache-tomcat-5.5.27.tar.gz

Créeons un utilisateur système tomcat afin de lancer le démon, et attribuer le propriétaire tomcat aux répertoires et sous-reps du serveur:

adduser tomcat
chown -R tomcat:tomcat /opt/apache-tomcat-5.5.27/
Pour plus de praticité, on va ajouter un lien symbolique histoire de racourcir le chemin…
ln -s /opt/apache-tomcat-5.5.27/ /opt/tomcat
Allez, on teste le tout: exit pour quitter root, su tomcat, puis /opt/tomcat/bin/start.sh

N’oubliez pas de rajouter :8080 (port par défaut de tomcat) après votre url pour vérifier que tomcat répond.

3 Lancement de tomcat

On va maintenant créer un script d’initialisation de tomcat qu’on pourra placer dans /etc/init.d/

Le script va etre très basique. Copiez collez ces instructions dans un fichier nommé tomcatd à placer dans /etc/init.d/

#!/bin/sh
TOMCAT_USER=tomcat
TOMCAT_PATH=/opt/tomcat
export JRE_HOME="/opt/jre1.6.0_07/"
export CLASSPATH="/opt/tomcat/lib/jsp-api.jar;/opt/tomcat/lib/servlet-api.jar"
start() {
echo -n "Starting Tomcat:  "
su $TOMCAT_USER -c $TOMCAT_PATH/bin/startup.sh
sleep 2
}
stop() {
echo -n "Stopping Tomcat: "
su $TOMCAT_USER -c $TOMCAT_PATH/bin/shutdown.sh
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo $"Usage: tomcat {start|stop|restart}"
exit
esac

Ensuite on rend le script executable : chmod 755 /etc/init.d/tomcatd
On va intégrer notre démon pour les runlevel 2/3/5 avec update-rc.d (n’oubliez pas les points qui terminent les commandes)
update-rc.d tomcatd start 42 2 3 5 . stop 31 0 6 .

4 Mise en place du connecteur (mod_jk mod_proxy) pour utiliser apache en frontend

Un proxy signifie qu’un serveur agit derrière un autre serveur. Apache httpd va donc jouer le role d’intermédiaire entre le client et notre conteneur de servlet. Il est indispensable de sécuriser Apache avant d’avtiver le mod_proxy, sous peine de permettre à n’importe qui d’accéder à internet depuis votre propre serveur!

Pour activer le proxy, il suffit de déclarer la directive globale activant l’utilisation du module éponyme (sur debian on va créer un fichier proxy.load qu’on placera dans /etc/mods-enabled/, pour les autres distrib, on écrira directement dans /etc/httpd/httpd.conf)

Les deux modules concernés sont mod_proxy et mod_proxy_ajp (pour activer le support du protocole apache j_serv).

LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
LoadModule proxy_ajp_module /usr/lib/apache2/modules//mod_proxy_ajp.so

On va maitenant créer le fichier tomcat.site dans le dossier /etc/apache2/sites-availables/ puis créer un lien symbolique dans /etc/apache2/ avec cette comande

ln -s /etc/apache2/sites-availables/tomcat.site /etc/apache2/sites-enabled/

Voici le contenu de ce fiohier:

<VirtualHost *:80>

ServerName votre_sous_domaine.votre_domaine.votre_tld

# pour éviter que le proxy soit ouvert, et pour transmettre les véritables hostname à tomcat
ProxyRequests Off
ProxyPreserveHost On

ErrorLog /var/log/apache2/tomcat.error.log
CustomLog /var/log/apache2/tomcat.log combined

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass / ajp://localhost:8009/tomcat-docs/
ProxyPassReverse / ajp://localhost:8009/tomcat-docs/

</VirtualHost>

Il ne nous reste plus qu’à faire écouter Tomcat sur le port du conecteur AJP, et ce sera bon!

On va donc éditer le fichier server.xml, et vérifier que les lignes suivantes sont bien présentes:

<Connector port= »8009″ address= »127.0.0.1″ enableLookups= »false » redirectPort= »8443″ protocol= »AJP/1.3″ />
On pourra désactiver tous les autres connecteurs pour être sur que tomcat ne soit pas accessible sans passer par le frontend.

Pour plus de renseignements, je vous conseille la lecture des articles suivants sur ce même blog:
– configurer correctement ses vhosts
– épurer la configuration du server.xml de tomcat

Tips et astuces : apprendre à configurer Apache httpd

Cet article est un fourre tout des directives de configurations du serveur web Apache les plus basiques. Il s’adresse donc aux débutants qui veulent apprendre comment configurer Apache (v.2.x).

N’hésitez pas à poser des questions parmi vos commentaires, je ferai de mon mieux pour y répondre. Si vous constatez une erreur, ou si vous voulez ajouter une précision, le commentaire sera bienvenu!

Généralités

Où placer les directives ?

Les directives sont à placer dans le contexte global (/etc/apache2/apache2.conf chez Debian, généralement /etc/httpd.conf ailleurs) mais peuvent etre restreinte spécifiquement à un « host » entre des balises <VirtualHost> où à un répertoire entre des balises <Directory>. Les directives doivent donc être placées là ou vous voulez qu’elles prennent effet !

Que signifie… ?

AllowOverride (None / All)

AllowOverride permet de spécifier si l’utilisation d’un fichier .htaccess sera prise en compte ou non.

DocumentRoot

Se place dans le contexte global ou dans un virual host pour donner le chemin (l’arborescence unix) à partir duquel le serveur web va servir les données. Exemple avec DocumentRoot = /var/www/test/

http://www.adresse_du_serveur.com/index.html affichera le fichier UNIX
    /var/www/test/index.html.

NameVirtualHost

NameVirtualhost est la directive qui permet d’associer une adresse ip au serveur afin qu’il redispatche les requêtes sur les Virtualhost. Afin d’écouter à la foi la boucle locale, et l’adresse ip propre du serveur, on peut mettre *, en spécifiant le port, en lieu et place de la seule adresse du serveur.

NameVirtualHost *:80

Options

Cette directive est un fourre tout, qui permet d’activer:

– L’éxécution de scripts CGI dans l’arborescence définie par documentRoot.(ExecCGI)
– Le suivi des liens symboliques au sein de l’arborescence du documentRoot (FollowSymLinks). Exemple: si un dossier est placé a l’etérieur du document root, pour y accéder, il suffit de taper un ls -n /dossierCible /votre_documentRoot/www/ pour y accéder.
– et bien d’autres options encore…que nous ne listerons pas ici.

ServerName

Cette rubrique permet d’associer un host apache a une adresse de type DNS. SI vous possedez le domaine MONDOMAIN.COM, et que vous avez configuré le DNS pour que sous-domaine.mon-domaine.com pointe sur l’ip de la machine sur laquelle tourne apache, alors vous pouvez définir le serverName suivant:

ServerName sous-domaine.mon-domaine.com:80

Ce sera tout pour aujourd’hui, avec ces quelques directives, vous pourrez aisément comprendre les fichiers d’example des <VirtualHost>. Vous avez également le nécessaire pour pouvoir associer des sites différents à chacun de vos sous domaines (si vos DNS sont bien configurés…).

AddDefaultCharset

J’avais oublié une irective quasiment indispensable: AddDefaultCharset
Vous voulez spécifier par défaut une locale spécifique ? bonne idée! Si votre serveur doit servir du contenu en plusieurs locales différentes, vous pouvez même associer un charset différent par vhost avec
AddDefaultCharset UTF-8

extensions d’Apache?

Apache peut être très facilement étendu grâce a un système de « modules ». Les modules Apache permettent d’ajouter de nouvelles fonctionnalités comme par exemple le traitement des requêtes, la mise en cache de fichiers, l’amélioration de la sécurité, etc.

Un module s’active avec la directive

LoadModule nom_du_module chemin_du_fichier

Le nom_du_module est une variable qui est est listée dans la liste des définitions de modules.

The fastest way to log4j …

.. ou 30s pour une webapp journalisée par Log4j

Depuis la version 5.5, le logger interne de tomcat est remplacé par log4j.

Quel intérêt à utiliser un systeme de logging externe ?

Si on utilise System.out.println(); , les sorties sont redirigées dans le cas d’une webapp vers le fichier catalina.out. Si on peut se contenter de cette méthode pour tester une webapp sur son pc, il est est autrement plus compliqué si l’on veut s’y retrouver sur un Tomcat contenant plusieurs webapps! De plus, la concurrence sur la sortie standard n’est pas gérée par System.out, et il n’est donc pas rare d’avoir deux applications mélangeant allègrement leurs logs en éditant simultanément catalina.out.

Log4j est populaire car il permet tres facilement de:
Séparer les fichiers de logs ( y compris pour une seule et meme application)
Hierarchiser les logs
Définir rapidement le niveau d’alerte souhaité (une infos de debug n’a pas la meme criticité qu’une alerte d’erreurs)

Voici un moyen rapide pour l’utiliser:

1 télécharger log4j ici :

http://logging.apache.org/log4j/1.2/download.html

2 recuperer le fichier log4j-*VERSION*.jar et le placer dans les librairies
– de la web app
– ou du serveur ( non testé)
(Dans le code faire attention lors en utilisant import à ne pas utiliser les librairies de java.util)

La programmation se fait en 3 lignes:

Code:

// initialisation du logger

Logger log = Logger.getLogger(« toto »); //toto est l’identifiant du logger

// définition de la criticité

log.setLevel(Level.INFO);

// ce qui remplace un appel a System.out.print();

log.info(« temps de requete pour rechercher les mesages: »+mytime );

Explication du niveau de log:
Une fois le niveau de log fixé, seul les traces d’un niveau de priorité supérieures au niveau fixé seront tracées.
Par exemple avec un setLevel= level.INFO, les log.debug(« message ») seront inactifs. (car level.DEBUG<level.INFO)

Ou placer ce code ?
L’initialisation du logger peut se faire dans une classe dédié, en la plaçant de manière statique dans le constructeur:Les appels se feront en tapant LogUtil.log.xxx();

public class LogUtil {
public static Logger log = Logger.getLogger(« main »);
}
Utiliser un fichier de properties:
Au lieu de définir les paramètres par programmation, il est recommandé d’utiliser un fichier de configuration. Voici a quoi ressemble mon Log4j.properties:

#définition du niveau et des Appender du rootLogger
log4j.rootLogger=DEBUG, monAppender

#configuration de « monAppender »
#nous allons envoyer les messages dans la console de Tomcat
#log4j.appender.monAppender=org.apache.log4j.ConsoleAppender

log4j.appender.monAppender=org.apache.log4j.DailyRollingFileAppender
log4j.appender.monAppender.File=/home/mulder/logdev.log
log4j.appender.monAppender.DatePattern=’.’yyyy-MM-dd

#définition du Layout pour « monAppender »
log4j.appender.monAppender.layout=org.apache.log4j.PatternLayout

#définition du pattern d’affichage pour « monAppender »
#voici un exemple de sortie que l’on va obtenir : 2005-06-18 14:53:37 DEBUG [Main] Hello World
log4j.appender.monAppender.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{1}] %m%n

Le fichier est automatiquement chargé s’il est placé dans le dossier WEB-ING/classes/ de la WEBAPP, ou COMMON/classes/ du serveur tomcat.