Le développement d’applications Web

François Charoy
Pascal Molli
Pascal Urso
License Creative Commons

  Cette création est mise à disposition selon le Contrat

Paternité-Pas d'Utilisation Commerciale-Partage des
Conditions Initiales à l'Identique 2.0 France disponible en
ligne
http://creativecommons.org/licenses/by-nc-sa/2.0/fr/ou par
courrier postal à Creative Commons, 171 Second Street,
Suite 300, San Francisco, California 94105, USA.

2 CC by-nc-sa
 Plan

•  Historique & objectifs

•  Présentation des Servlets
•  Spécificité
•  Sécurité
•  Les JSP
•  Architecture MVC web
•  Framework JSF

3 CC by-nc-sa
Premier browser sur NeXt

4 CC by-nc-sa
Application Web

5 CC by-nc-sa
Web 1.0 vs Web 2.0

6 CC by-nc-sa
Modèle de conversation

7 CC by-nc-sa
 Short History
•  1980 : HTML 0.9
•  1990 : Scripts CGI
–  Programmes C, shell scripts, perl, ...
•  1994 : Langages spécifiques
–  PHP, JSP, ASP (Server Side scripting)‫‏‬
–  JavaScript (Client Side Scripting)‫‏‬
•  2002 : Evolutions de HTML
–  XHTML, CSS, JavaScript

8 CC by-nc-sa
Aggrégation

9 CC by-nc-sa
10 CC by-nc-sa
Mashups
  Composition d'application Web
  Composition/Filtre de sources de données
  Composition d'applications
  Google Maps + bases de données
  Yahoo Pipes
  ...

11 CC by-nc-sa
Service Web/Rest
  Exposition des API
  Exemple : Twitter

12 CC by-nc-sa
Conclusion
  Les applications Web sont le cœur du Web-2.0
  Et ça ne fait que commencer...
  Pour développer des appli web pertinentes:
  Vous avez besoin de «comprendre» le web
  Vous avez besoin de comprendre les problèmes techniques pour
faire des applications Web évolutives, sécurisées, tolérantes aux
pannes, composable
  Vous devez comprendre les problèmes spécifiques des
applications web pour rendre les applications Web utilisables,
maintenable et sûres

13 CC by-nc-sa
 Developping Web Applications :
Introduction to Servlets

14 CC by-nc-sa
Couches de protocole du WWW
  Modèle OSI

7. Couche application HTTP

6. Couche de présentation HTML, MIME
5. Couche de session non
4. Couche de transport TCP
3. Couche de réseau IPv4, IPv6
2. Couche de liaison whatever
1. Couche physique whatever

15 CC by-nc-sa
Requête HTTP
  Quelques lignes de texte
  Ligne de commande : commande, url, version de protocole
  Entête de requête
  [ligne vide]
  Corps de requête (optionel : paramêtres, appel soap, …)
POST /fichier.ext HTTP/1.1
Host: www.site.com
Connection: Close
Content-type: application/x-www-form-urlencoded
Content-Length: 33
<nouvelle ligne>
variable=valeur&variable2=valeur2

16 CC by-nc-sa
Commandes HTTP
  Demande sans effet de bord (en théorie)
  GET ressource
  HEAD information sur une ressource
  OPTIONS options de communication
  CONNECT utilisation de proxy
  TRACE journal de serveur
  Demande avec effet de bord (en théorie)
  POST soumission de données
  PUT ajout/màj d’une ressource
  DELETE suppression d’une ressource
  Usuellement seulement GET et POST
17 CC by-nc-sa
Réponse HTTP
  Quelques lignes de texte
  Ligne de statut : version de protocole, code, message
  Entête de réponse
  [ligne vide]
  Corps de requête (optionel : ressource, url, rép. soap, …)
HTTP/1.0 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Server: Apache/0.8.4
Content-Type: text/html
Content-Length: 59

<TITLE>Exemple</TITLE>
<P>Ceci est une page d'exemple.</P>

18 CC by-nc-sa
 Quels sont les problèmes ?
  Protocole HTTP
  Stateless
  Clients multiples et inconnus
  Identification des utilisateurs
  Maintient des sessions
  Requêtes et réponses statiques
  Application distribuée
  Concurrence d’accès
  Sécurité
  Passage à l’échelle

19 CC by-nc-sa
 Les Servlets

•  Permettre la programmation d'applications coté serveur

•  Permettre l'extension d'un serveur Web en java
•  Permettre la construction d'appli Web dynamique
•  ~Equivalent fonctionnel des CGI en java

20 CC by-nc-sa
Ressources
  Référence
http://java.sun.com/javaee
  API
http://java.sun.com/javaee/6/docs/api/
  Tutorial
http://java.sun.com/javaee/6/docs/tutorial/doc/
  Java Specification Requests
  Servlet
http://jcp.org/aboutJava/communityprocess/pfd/jsr315/index.html
  JSP
http://jcp.org/aboutJava/communityprocess/final/jsr245/index.html
21 CC by-nc-sa
Fonctionnement d'un servlet
  Un servlet lit les données envoyées par un client Web
(transmises par le serveur)
  Données explicites (Formulaire)
  Données implicites (Request Header)
  Il génère un résultat
  Il envoit le résultat au client
  Données explicites (Page HTML)
  Données implicites (Response Header, Status code)
Database
Serveur Jndi
Web Java App

22 CC by-nc-sa
Serveur d'application JEE
  Fournit un ensemble de services pour l'écriture
d'application distribuées en Java
  Nommage
  Transactions
  Sécurité
  Conteneur Web

Pourquoi Java ?
23 CC by-nc-sa
 Avantage des servlets

  Efficacité
  Utilisent des threads plutôt que des processus comme les CGI
  Pratique
  Librairie très développée (moins que PHP mais plus consistante)
  Portable
  Déployable quelque soit le serveur (ou presque)
  Sécurisé
  Fonctionne dans une machine virtuelle (plus maitrisable)
  Pas cher
  Nombreux serveurs gratuits

24 CC by-nc-sa
L’architecture

25 CC by-nc-sa
La partie Web

26 CC by-nc-sa
Les containers de servlet

  Les servlets sont des composants

  Ils s'exécutent dans un container
  Ils doivent se conformer à une interface prédéfinie
  C’est le container qui décide de leur instantiation
  Les containers
  Environnement d’exécution des servlets
  Tomcat (jakarta.apache.org/tomcat)‫ ‏‬
  Jetty
  Weblogic
  Glassfish

27 CC by-nc-sa
L’exécution d’un servlet

28 CC by-nc-sa
Un premier servlet
  Le servlet HelloWorld
  Un servlet surcharge la classe HttpServlet
  Il doit implanter au moins une des méthodes
  doGet
  doPost
  doPut
  doDelete

29 CC by-nc-sa
Le servlet HelloWorld

30 CC by-nc-sa
Le fichier de configuration

31 CC by-nc-sa
Servlet 3.0 : annotations

Avoid the configuration

file

32 CC by-nc-sa
Un module Web
  Déployable et exécutable dans un serveur Web

33 CC by-nc-sa
 L’application Web
•  Une archive war
•  Déployée dans le serveur
Web
•  Web.xml = description de
l’application
Structure d’une application
  Package déployable
  Composants Web : Servlet et JSP
  Ressources statiques (images)
  Classes java (helper)
  Librairies
  Descripteurs de déploiement (web.xml)

35 CC by-nc-sa
 Execution d’une requête

36 CC by-nc-sa
Exécution d’une requête
  Objet HttpServlet
  Objets HttpServletRequest, HttpServletResponse
  Paramètres de requête,
  Header de requête
  Cycle de vie des servlet

37 CC by-nc-sa
La classe HttpServlet

38 CC by-nc-sa
doGet et doPost

39 CC by-nc-sa
L'interface HttpServletRequest
  Fournit les informations sur la requête du client au serveur
  Principales méthodes (pour l'instant):
  String getParameter(String name)
  Enumeration getParameterNames()
  Retourne une énumération de tous les noms de paramètres
  String[] getParameterValues()
  Retourne un tableau contenant toutes les valeurs des paramètres
  String getHeader(String name)
  Enumeration getHeaderNames()
  Retourne une énumération de tous les noms des propriétés du header
  String[] getHeaderValues()
  Retourne un tableau de toutes les valeurs du header

40 CC by-nc-sa
Les paramètres
  Les paramètres d'une requête sont accessibles dans l'objet
(HttpServletRequest) request
  request.getParameter("paramname");
  Il est possible de récupérer tous les noms des paramètres
  request.getParameterNames()

41 CC by-nc-sa
Exemples paramètres

42 CC by-nc-sa
Exemple POST

http://www.cs.cornell.edu/projects/
ladis2009/program.htm

43 CC by-nc-sa
Exemple POST (suite)

44 CC by-nc-sa
Nombre de requêtes HTTP : 2
  http://localhost:8084/CoursWeb/formulaire.html (GET)

  http://localhost:8084/CoursWeb/myForm (POST)

45 CC by-nc-sa
Les request headers

46 CC by-nc-sa
L'interface HttpServletResponse
  Objet fournissant les services pour envoyer la réponse à un
client.
  Les principales méthodes sont:
  java.io.PrintWriter getWriter()
  Pour récupérer un printWriter qui permet d'envoyer du texte au client
  public void setContentLength(int len)
  Positionne le Content-Length Header
  public void setContentType(java.lang.String type)
  Position le Content-Type header (exemple text/html)
  public void sendError(int sc, java.lang.String msg) throws
java.io.IOException
  Envoi un message d'erreur au client (cf code dans l'API)
  public void setHeader(java.lang.String name, java.lang.String value)

47 CC by-nc-sa
web.xml
  Le fichier web.xml donne des instructions sur le
déploiement du servlet dans le container
  web-app
  La description d'une Web Application
  Servlet
  La relation entre le nom du servlet et la classe qui l'implante
  Servlet-mapping
  La relation entre le nom du servlet et l'url qui permet d'y accéder
  Servlet 3.0 : remplacement possible par annotations @
  Plus « élégant »
  Moins « modulaire »
48 CC by-nc-sa
Les paramètres d'initialisation
  Les servlets peuvent avoir des paramètres d'initialisation.
  Ces paramètres peuvent être changés sans avoir à
recompiler l'application
<init-param>
<param-name>testValue</param-name>
<param-value>12</param-value>
<description>une valeur quelconque</description>
</init-param>

  Ces paramètres peuvent être utilisés avec la méthode

  javax.servlet.ServletConfig.getInitParameter()
  Annotation attribut @WebInitParam

49 CC by-nc-sa
Exemple

50 CC by-nc-sa
Le servlet mapping
  Permet de construire la relation entre un servlet et son
URL
<servlet-mapping>
<servlet-name>Test</servlet-name>
<url-pattern>/Test/*</url-pattern>
</servlet-mapping>

  Tous les urls correspondant à

http://host:port/webapp/url-pattern déclencherons
l’exécution du servlet
  Exemples
  /*.do
  /Test
51  /cours/test/* CC by-nc-sa
Servlet mapping (annotations)
@WebServlet(”/foo”)
public class A extends HttpServlet {
public void doGet(HttpServletRequest req,
HttpServletResponse res) { ... }
}

@WebServlet(name=”MyServlet”, urlPatterns={"/foo*", "/bar"},

initParams = {
@WebInitParam(name="x", value="Hello "), @WebInitParam
(name="y", value=" World!") })
public class B extends HttpServlet {
...
}

52 CC by-nc-sa
Les éléments du chemin de requête
  ContextPath : le chemin du contexte de déploiement
  ServletPath : la section du chemin qui a déclenché le
mapping
  PathInfo : la partie de la requête qui n’est ni le
ContextPath ni le ServletPath
  Request.getContextPath()
  Request.getServletPath()
  Request.getPathInfo()

53 CC by-nc-sa
Exemples

54 CC by-nc-sa
Autre propriétés
  Pour le mapping mime
  <mime-mapping>
  Pour les fichiers à charger quand un nom de répertoire est
donné
  <welcome-file-list>
  Pour les pages d'erreur
  <error-page>
  Pour chaque code d'erreur on peut fixer une page spécifique
  Il y en a d'autres pour
  La sécurité
  Les taglibs
55  Les références aux ressources utilisés CC
parby-nc-sa
les servlets
Le cycle de vie d'un servlet
  Tous les servlets ont le même cycle de vie
  Le container charge le servlet
  La fonction init() est appelée (initialisation de variables, connection à des bases de
données)
  Le servlet répond aux requêtes des clients
  Le container détruit le servlet
  La fonction destroy() est appelée (fermeture des connections)

56 CC by-nc-sa
Servlet Life Cycle

57 CC by-nc-sa
 Ecrire une application Web

58 CC by-nc-sa
Ecrire une application Web
  Gestion des paramètres
  Application
  Session

  RequestDispatcher
  Listeners
  Filtres
  Wrapper
  Erreurs
  Sécurité
59 CC by-nc-sa
 La visibilité

(from jGuru)
60 CC by-nc-sa
 Le ServletConfig

  Objet utilisé par le container de servlet pour passer des

valeurs lors de l'initialisation du servlet
  Obtenu avec
  Servlet.getServletConfig()
  Principales méthodes
  String getInitParameter(String name)
  Retourne la valeur d'un paramètre d'initialisation du servlet
  ServletContext getServletContext()
  Permet de récupérer l'objet servletcontext
  String getServletName()
  Retourne le nom du servlet comme spécifié dans le fichier de description.
  Implanté par HttpServlet

61 CC by-nc-sa
 Le Servlet Context
  Maintien des données pour toute l’application
  Fournit le request dispatcher
  Données d’initialisations pour toute l’application
  Log
  Un ServletContext par application et par JVM

62 CC by-nc-sa
Le ServletContext
  Objet permettant au servlet de communiquer avec le servlet
container
  Obtenu avec
  Servlet.getServletContext()
  Les principales méthodes de ServletContext
  Object getAttribute(String name)
  Retourne un attribut du contexte
  void setAttribute(String name, Object value)
  Ajoute ou remplace un objet dans le contexte
  String getInitParameter(String name)
  Retourne un paramètre d'initialisation de l'application
  void log(String msg)
  Ajoute un message dans le log file du servlet container
63 CC by-nc-sa
Le Servlet Context

64 CC by-nc-sa
Les attributs du context
  Valeurs disponibles pour toute l’application

65 CC by-nc-sa
Le contexte
  Il est possible d'avoir des paramètres d'initialisation du
contexte
<context-param>
<param-name>database</param-name>
<param-value>testDB</param-value>
<description>le nom de la base</description>
</context-param>

  Ces paramètres peuvent être utilisés dans le servlet avec

la méthode
  Javax.servlet.ServletContext getInitParameter() et
  Javax.servlet.ServletContext.getInitParameterNames()

66 CC by-nc-sa
 La visibilité

(from jGuru)
67 CC by-nc-sa
Les Sessions
  Comment maintenir l’état d’un client au cours d’une série
de requêtes d’un même utilisateur pendant un temps
donné ?
  HTTP est stateless
  Comment identifier le client ?
  Où mettre les données de la session ?

68 CC by-nc-sa
Servlet et sessions
  La gestion des sessions utilise les techniques classiques
  url rewriting
  Cookies
  Champs cachés dans les formulaires
  L'API HttpServlet fournit des fonctions pour gérer les
sessions
  L'implantation est casi-transparente pour l'utilisateur

69 CC by-nc-sa
Session & HttpServletRequest
  C'est le paramètre request qui maintient les informations
sur la session
  Les méthodes sont
  HttpSession request.getSession(boolean flag)
  Flag=true : retourne l'objet session courant ou en crée un s'il n'y en a
pas.
  Flag=false : Retourne l'objet session courant ou null s'il n'y en a pas
  isRequestedSessionIdValid()
  Vrai si l'id de la session est valide dans le contexte courant
  isRequestedSessionIdFromCookie()
  Vrai si l'id de la session vient d'un cookie
  isRequestedSessionIdFromURL()
70   Vrai si l'id de la session vient d'un URL CC by-nc-sa
Création de la session

71 CC by-nc-sa
Requête dans la même session

72 CC by-nc-sa
L'objet HttpSession

L'objet HttpSession permet de conserver des valeurs entre des appels d'un
client
  Les principales méthodes sont
  Object getAttribute(String name)   String getId()
  Récupère la valeur de l'attribut par   Retourne l'identifiant de la session
son nom
  void invalidate()
  Enumeration getAttributeNames()
  Invalide la session
  Retourne la liste de tous les attributs
  long getCreationTime()
  void setAttribute(String name, Object
  long getLastAccessedTime()
value)
  long getMaxInactiveInterval()
  Ajoute un attribut à la session
  ServletContext getServletContext()

73 CC by-nc-sa
Cookies
  Création de cookies

74 CC by-nc-sa
Cookies

75 CC by-nc-sa
Getting cookies values

76 CC by-nc-sa
Fin de vie d’une session

  Au niveau programmatique

  Fermeture automatique en fixant la durée de vie (en

minutes)
<session-config>
<session-timeout>30</session-timeout>
</session-config>

77 CC by-nc-sa
 Ecrire une application Web

RequestDispatcher

78 CC by-nc-sa
Le RequestDispatcher
  L'objet RequestDispatcher est utilisé pour
  Transférer la requête à un autre programme
  Inclure la réponse d'un autre programme
  Pour obtenir le request dispatcher

79 CC by-nc-sa
L'utilisation du RequestDispatcher
  La requête peut être transférée
  rd.forward(request,response)
  L'utilisation classique consiste à avoir un servlet contrôleur qui
transmet les commandes à des servlets spécialisés
  Pas d’écriture sur la réponse avant le forward (exception)
  Le contrôle revient au servlet
  Ecritures sur la réponse ignorés après le forward
  La réponse peut être incluse dans la réponse en cours de
construction
  rd.include(request,response)
  Ici, on peut implanter un équivalent de server side include.

80 CC by-nc-sa
Exemple d’utilisation

Démonstration !

81 CC by-nc-sa
82 CC by-nc-sa
 Ecrire une application Web

Listeners

83 CC by-nc-sa
Les listeners
  Les listeners sont des objets dont les méthodes sont
invoquées en fonction du cycle de vie d'un servlet
  A la création et à la destruction d'un contexte (une appli)
  javax.servlet.ServletContextListener
  Quand on modifie les attributs du contexte
  javax.servlet.ServletContextAttributeListener
  A la création, la suppression, le timeout d'une session
  javax.servlet.HttpSessionListener
  A la création, modification, suppression d'un attribut de
session
  javax.servlet.HttpSessionAttributeListener
84 CC by-nc-sa
Pourquoi des listeners ?
  Pour une application Web
  Pas de point d’entrée (main)
  Pas d’exit()
  Comment faire pour initialiser l’application ?
  Pour une session
  Possibilité de démarrer à plusieurs adresses (bookmarks,
recherche)
  Comment initialiser la session ?
  Pas de fin de session explicite.
  Comment terminer la session ?

85 CC by-nc-sa
 Les listeners du contexte
ServletContextListener
void contextDestroyed(ServletContextEvent sce)
Notification that the servlet context is about to be shut
down.
void contextInitialized(ServletContextEvent sce)
Notification that the web application is ready to process
requests.

ServletContextAttributeListener
void attributeAdded(ServletContextAttributeEvent scab)
Notification that a new attribute was added to the servlet
context.
void attributeRemoved(ServletContextAttributeEvent scab)
Notification that an existing attribute has been remved from the
servlet context.
void attributeReplaced(ServletContextAttributeEvent scab)
Notification that an attribute on the servlet context has been
replaced.
86 CC by-nc-sa
 Les listeners de session
HttpSessionListener
void sessionCreated(HttpSessionEvent se)
Notification that a session was created.
 void sessionDestroyed(HttpSessionEvent se)
Notification that a session was invalidated.

HttpSessionAttributeListener
 void attributeAdded(HttpSessionBindingEvent se)
Notification that an attribute has been added to a session.
 void attributeRemoved(HttpSessionBindingEvent se)
Notification that an attribute has been removed from a
session.

 void attributeReplaced(HttpSessionBindingEvent se)
Notification that an attribute has been replaced in a session.

87 CC by-nc-sa
La déclaration d’un listener
  web.xml
<listener>
<listener-class>
cours.exemple1.SessionCounter
</listener-class>
</listener>
  Il n’est pas nécessaire de préciser le type du Listener (pourquoi ?)

  Annotation @WebListener

88 CC by-nc-sa
Exemple

89 CC by-nc-sa
Un autre exemple

90 CC by-nc-sa
Exemple (Servlet 3.0) avec déclarations

91 CC by-nc-sa
 Ecrire une application Web

Filtres

92 CC by-nc-sa
Les filtres
  Un filtre est un morceau de code exécuté entre la requête
et le « endpoint »
  Permettent de faire du pre et post-processing sur une
requête
  Lire la requête, modifier la requête modifier la réponse,
retourner des erreurs au client
  Même cycle de vie qu’un servlet
  init / doFilter / destroy

93 CC by-nc-sa
Intérêt des filtres
  Permettent d’étendre l’application sans changer les
servlets
  Services transversaux en entrée et en sortie
  En entrée
  Log des appels
  Sécurité
  Contrôle des paramètres
  En sortie
  Post processing du flux (XSLT)
  Compression (gzip)
  Fonctionnent comme un pipe & filter
94 CC by-nc-sa
Coder un filtre

  Implanter la méthode doFilter()‫‏‬

  Déclarer le filtre
  web.xml : <Filter> <Filter-mapping>
  Servlet 3 : @WebFilter("cible")
  Même fonctionnement que pour un servlet
  Le transfert à la suite de la chaine se fait par la fonction
chain.doFilter()‫‏‬
  Transfert à un autre filtre ou à un servlet ou une page HTML
ou une page JSP
  La suite s’exécute au retour de doFilter

95 CC by-nc-sa
Exemple (généré par NetBeans)

96 CC by-nc-sa
PreProcessing
  Affichage des paramètres

97 CC by-nc-sa
PotsProcessing

  Ajout de texte dans la sortie

98 CC by-nc-sa
Le servlet filtré

99 CC by-nc-sa
L’exécution

Sur le serveur

100 CC by-nc-sa
Wrapping
  Principe : encapsuler l’objet requête ou l’objet réponse
pour modifier son comportement
  Encapsulation de request : surcharge
HttpServletRequestWrapper
  Encapsulation de reponse : surcharge de
HttpServletRequestResponse
  Ensuite il suffit de remplacer l’objet wrappé.
  Le Wrapping peut aussi être utilisé dans des Servlets
normaux.

101 CC by-nc-sa
Le Wrapping des réponses
  Plus compliqué que pour les requêtes
  Nécessite de
  récupérer la réponse d’abord
  Ou d’écrire un Writer spécialisé
  Utilisations classiques
  Caching des réponses
  Compression des réponses

102 CC by-nc-sa
 Ecrire une application Web

Erreurs

103 CC by-nc-sa
 La gestion des erreurs
  Il est possible de définir les pages à afficher
  En fonction d'erreurs http
  En fonction d'exceptions java

Pour une
Dans web.xml exception java
<error-page>
<exception-type>
cours.event.EventException
</exception-type>
<location>/erreur.html</location>
</error-page>
Pour une erreur
Http
<error-page>
<error-code>404</error-code>
<location>/404.html</location>
</error-page>
104 CC by-nc-sa
Codes HTTP
  100 : Continue : Attente de la suite de la requête
  200 : OK : Requête traitée avec succès
  201 : Created : Requête traitée avec succès avec création d'un document
  204 : No Content : Requête traitée avec succès mais pas d'information à
renvoyer
  303 : See Other : La réponse à cette requête est ailleurs
  400 : Bad Request : La syntaxe de la requête est erronée
  401 : Unauthorized : Une authentification est nécessaire
  403 : Forbidden : L'authentification est refusée
  404 : Not Found : Document non trouvé
  414 : Request-URI Too Long : URI trop longue
  500 : Internal Server Error : Erreur interne du serveur
  …
105 CC by-nc-sa
 Ecrire une application Web

Sécurité

106 CC by-nc-sa
Servlet et sécurité (from servlet spec)
  A web application contains resources that can be accessed
by many users.
  These resources often traverse unprotected, open
networks such as the Internet.
  In such an environment, a substantial number of web
applications will have security requirements.
  Authentication
  Access Control
  Data Integrity

107 CC by-nc-sa
Sécurité
  The Servlet Container support declarative security and
programmatic security.
  Declarative : Security policies are declared in deployement
descriptor (web.xml) or as annotation
  Programmatic security allow servlet developers to directly
interact with security API of the container.
  Use it carefully (only if declarative security is not sufficient)

108 CC by-nc-sa
Declarative security
<security-constraint>
<web-resource-collection>
<web-resource-name>SalesInfo </web-resource-name>
<url-pattern>/salesinfo/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>manager</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL </transport-
guarantee>
</user-data-constraint>
</security-constraint>
109 CC by-nc-sa
Security constraints

110 CC by-nc-sa
Modèle de sécurité
  Basé sur des rôles
  Groupes d’utilisateurs
  Accès aux servlet/méthodes
  Ne fournit pas de gestion fine des droits d’accès aux donnés
  Au déploiement, les rôles sont mappé sur des groupes
  sun-applicaton.xml (glassfish)
<security-role-mapping>
<role-name>pouet</role-name>
<group-name>utilisateur</group-name>
</security-role-mapping>

111 CC by-nc-sa
Security model

Les users ayant endossé

le rôle « pouet » ont le
droit de requéter /World

Peut être changé par le

« deployer »

112 CC by-nc-sa
 Le rôle « pouet » est associé au groupe « pouet » déclaré sur glassfish,
pour l'application web MyHello

113 CC by-nc-sa
Gestion des utilisateurs (Tomcat)
  Propre au container web
  Tomcat :
  De manière statique dans le $TOMCAT_HOME/conf/tomcat-
users.xml
<tomcat-users>
<role rolename="chat"/>
<role rolename="souris"/>
<user username="tom" password="miaou" roles="chat"/>
<user name="admin" password="pw" roles="chat,souris" />
</tomcat-users>
 

114 CC by-nc-sa
Gestion des utilisateurs
  Définis dans un domaine
  FileRealm
  JDBCRealm
  CustomRealm
  LDAPRealm, ...

115 CC by-nc-sa
Déclarer les users dans le « runtime »

116 CC by-nc-sa
Authentication
  A web client can authenticate a user to a web server using
one of the following mechanisms:
  HTTP(S) Basic Authentication
  HTTP Digest Authentication
  HTTP(S) Client Authentication
  Form Based Authentication
  Programmatic Authentication

117 CC by-nc-sa
Authentication : Basic
  Couple username / password
  Définie par la spécification HTTP/1.0
  Pas sécurisé
  passwords envoyé en encoding base64
  le serveur cible n’est pas authentifié
  Requière HTTPS ou IPSEC/VPN pour assurer plus de sécurité

118 CC by-nc-sa
Security model

Contrainte
de sécurité

Authentication
« BASIC »
Déclaration
de rôle
119 CC by-nc-sa
Accès sécurisé à la servlet « World »

120 CC by-nc-sa
Authentication : Digest
<login-config>
<auth-method>DIGEST</auth-method>
<realm-name>Digest Authentication Example</realm-name>
</login-config>

  Similaire à l’authentication basic

  Couple username / password
  Gestion des utilisateurs par le container web
  Password non transmis
  Le navigateur envoi un digest : hash cryptographié du username/
password/URI/nonce (usage unique)
  Danger : stockage des passwords en clair pour calculer le digest
  Peu implanté
121 CC by-nc-sa
Authentication « form login »
  web.xml
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/pageDeLogin.jsp</form-login-page>
<form-error-page>/pageDErreur.jsp</form-error-page>
</form-login-config>
</login-config>
  pageDeLogin.jsp
<form action="j_security_check" method="post">
<input type="text" name="j_username"/>
<input type="password" name="j_password"/>
<input type="submit" value="Connexion"/>
</form>

122 CC by-nc-sa
David Geary
Nov 30, 2001

123 CC by-nc-sa
Authentication « form login »
  Même problèmes que l’authentication BASIC
  password transmis en clair
  Stockage des password côté serveur
  Gestion des utilisateurs par le container
  Requière aussi HTTPS ou IPSEC/VPN pour assurer plus de
sécurité

124 CC by-nc-sa
Authentication « programmatique »
  Methodes de l’interface HttpServletRequest (J EE 6) :
  authenticate()
  Demande au container d’effectuer l’authentification
  login()
  avec login/password
  logout()
  getRemoteUser()
  Nom de l’utilisateur (null si personne)
  isUserInRole()
  getUserPrincipal()
  Retourne le java.security.Principal correspondant à l’utilisateur

125 CC by-nc-sa
Sécurité et annotation (servlet 3)
  Annotation sur une servlet OU une do-méthode (doGet,
doPut, doHead, …)
  Déclaration des rôles
  @DeclareRoles ("role1")
  Rôles autorisés
  @RolesAllowed("role1"), @RolesAllowed({"role1", "role2"})
  Mode de transport (HTTPS ou HTTP)
  @TransportProtected
  Autorisation globale
  @PermitAll, @DenyAll

126 CC by-nc-sa
Sécurité et annotation : exemple
@WebServlet("/myurl")
@RolesAllowed("javaee")
@TransportProtected
public class TestServlet extends HttpServlet {
...
@RolesAllowed("staff")
protected void doPost(HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException {
...
}
@TransportProtected(false)
@PermitAll
protected void doTrace(HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException {
...
}
}
127 CC by-nc-sa
Accès sécurisé à une méthode (Servlet 3)
@WebServlet("/myurl")
@RolesAllowed("javaee")
@TransportProtected
public class TestServlet extends HttpServlet {
...
@RolesAllowed("staff")
protected void doPost(HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException {
...
}
@TransportProtected(false)@PermitAll
protected void doTrace(HttpServletRequest req,
HttpServletResponse res)
throws IOException, ServletException {
...
}
}
128 CC by-nc-sa
 Conclusion Servlet

129 CC by-nc-sa
Conclusion
  The servlet model is a component model
  Servlet developpers have to conform to the model
(implements HttpServlet class)
  The Servlet container offers:
  Web application lifecycle management
  Distributed container
  Security management
  Servlet composition (by dispatching)
  Interception (through filters)
  Session management facilities

130 CC by-nc-sa
What we have not seen
  Distributed Servlet container over a cluster of computers
  Asynchronous servlet (Servlet 3.0)
  Web Fragment :
  Make Web application by composition web application fragment...

131 CC by-nc-sa
Servlet limitations
  Request/Response model can decrease maintainability...
  The business logic of application are in servlets
  HTML code or XHTML code is embedded in servlet...
  Need an higher abstraction level
  to leverage maintainability problems
  To speed up coding stage (RAD, rapid application development)...

132 CC by-nc-sa