[Struts-Tiles] Pages à accès reservé

**vallica** · 21/04/2006, 08h09

Bonjour tout le monde !

Voilà je code actuellement une appli Struts dans laquelle j'utilise Tiles, afin d'avoir toujours une structure sur un tableau à 3 lignes dans lesquelles j'inclu des jsp en fonction de la page sur laquelle je veux être :

---------
header
---------
menu
---------
contenu
---------

Actuellement, le premier écran est une demande de login classique, qui si succès forward vers l'index qui a la structure définie ci-dessus.

Tiles se base sur un layout principal, une sorte de squelette pour la mise en page qui est une jsp que j'ai définie ainsi :

<%@ taglib uri="/WEB-INF/struts-tiles.tld" prefix="tiles" %>
<HTML>
<HEAD>
<link rel="stylesheet" href="/gesam/gui-tiles/styles.css" type="text/css">
<title><tiles:getAsString name="title" /></title>
</HEAD>
<body>
<table id="tblLayout" align="center">
<tr id="trHeader">
<td>
<img src="images/banniere.png" alt="GESAM"/>
</td>
<td id="tdHeaderExt">
 
</td>
<td>
<img src="images/banniere2.png" alt="GESAM"/>
</td>
</tr>
<tr id="trMenu">
<td colspan="3"><tiles:insert attribute="header" /></td>
</tr>
<tr id="trCentre" >
<td valign="top" colspan="3" align="left">
<tiles:insert attribute='body' />
</td>
</tr>

</table>
</body>
</html>

Actuellement, aucun contrôle n'est fait à l'intérieur de l'appli, pour voir si la personne est autorisée à accèder aux ressources, ce qui n'est pas correct, car si on rentre une url ou si on appelle une action via le navigateur, on accède à la page sans être authentifié.

J'ai pensé à une solution qui consisterai à placer en session un attribut quelconque, une valeur drapeau que je pourrais tester (avec un <logic>) dans le layout que je vous ai montré ci-dessus. Si la valeur y est on affiche le <tr> dans lequel est inclu le body, sinon on affiche un message d'avertissement.

Je voulais savoir si vous pensez que cette solution est assez sécurisée, en sachant tout de même que l'appli tourne uniquement sur un intranet.

Merci d'avance

**sleepy2002** · 21/04/2006, 08h20

Salut,

si on revient au modèle MVC, l'authentification et la restriction de l'accés aux pages devrait se faire au niveau Controlleur, cad dans un contexte Struts, au niveau de ton action.

Au debut de ta méthode execute tu vas vérifer d'abord si la personne est connectée (il vaut mieux externaliser ça au cas où si tu dois passer d'une authentification locale à globale avec un LDAP par exemple). Ensuite propre à ton action, tu vérifies si l'utilisateur possède bien les droits adéquats. D'où l'utilité de sauver en session un objet UserInfo avec infos de base de l'utilisateur + listes des droits associés.

Suivant le cas tu rediriges vers le tiles adéquat.

**vallica** · 21/04/2006, 08h28

D'accord, donc tu me confirme que je devrais faire ca dans absolument toutes les Actions de mon appli? parce que j'en ai déjà une bonne 12aine...

Effectivement si je crée une classe Acces avec une méthode statique qui va voir en session si l'user a les droits et renvoi un booléen, j'ai juste à faire un

if (Acces.verif())
return mapping....

au début de tous mes execute c'est ca?

**sleepy2002** · 21/04/2006, 08h57

En fait,

tu peux redéfinir la classe Action de Struts genre MonProjectBaseAction.

dans la methode execute tu appelles ta methode d'authentification ensuite tu appelle une methode abstraite continueExecute (avec les mêmes paramètres que la méthode execute). Cette méthode abtraite tu la déclare dans cette classe dérivée. La méthode d'autentification peut être externalisée dans une classe utilitaire par exemple (comme ça tu découples bien).

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
public class MonProjetBaseAction extends Action {
 
   protected ActionForward execute(ActionMapping mapping, ActionForm form, HttpRequest req, ...) {
      ...
      if (!Authentification.verifier(request)) {
         //return vers la page de connexion avec un message d'erreur en plus par ex.
      }
      ...
      actionForward = continueExecute (mapping, form req, ...);
      ...
      //traiter les exceptions Bdd et metier et système et forwarder vers la page spécifique si besoin
 
      return actionForward;
   }
 
  protected abstract continueExecute (ActionMapping mapping, ActionForm form, HttpRequest req, ...) throws Exception {};
}

Ensuite vient l'écriture de tes actions concrète :

Tu rédéfinies la méthode abstraite propre à ton action. Dans cette action tu appelle ta méthode qui va vérifier les droits d'accés. Cette méthode peut être déclarée dans la classe.

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
19
 
 
public class MonAction1 extends MonProjetBaseAction {
  public ActionForward executeAction(
        ActionMapping mapping,
        ActionForm form,
        HttpServletRequest request,
        HttpServletResponse response) throws Exception {
 
    ...
    verifierDroitsAcces(session);
    ...
  }
 
  private boolean verifierDroitsAcces(HttpSession session) {
 
    //verifier les droits ici
  }
}

J'ai bossé sur une webapp avec plus de 250 Actions. Ca nous a bien aidé surtout lors de la phase d'intégration avec le LDAP lors de la 5ème itération du projet.

J'espère qu'il n'y a pas trop de boulettes et coquilles dans le code.

**vallica** · 21/04/2006, 09h03

merci beaucoup pour cet exemple concret et complet !

Juste une question par rapport à ta grosse webapp dont tu parles, pourquoi ne pas avoir utilisé un système style Jguard ou JAAS dans un projet d'une telle envergure?

**sleepy2002** · 21/04/2006, 09h11

Parce que le client avait homologué ce qu'il fallait utiliser (hé oui ça existe).

Par exemple : Tomcat 4 mais pas le 5, concernant l'authentification il fallait utiliser leur API LDAP SSO.

Concernant le développement même, les besoins n'étaient pas tous finalisés au départ, c'est venu petit à petit. Même si on a essayé de bien modulariser les choses c'est devenu une usine à gaz. Enfin bon, il est clos depuis 3 mois ce projet, ouf !

.

**zekey** · 21/04/2006, 09h14

La méthode standard consiste à utiliser le mécanisme de sécurité standard J2EE c'est à dire les constraints:

Dans ton web.xml tu définis:

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
 
<security-constraint>
  <web-resource-collection>
    <web-resource-name>
      restricted
    </web-resource-name>
 
    <url-pattern>/restricted/*</url-pattern>
  </web-resource-collection>
 
  <auth-constraint>
    <role-name>admin</role-name>
 
  </auth-constraint>
</security-constraint>

Remarque l'url pattern, il suffit de donné le nom de tes actions associé au role. Tu trouvera plein d'exemples à ce sujet sur ce site.

**sleepy2002** · 21/04/2006, 09h17

Exact notamment pour des fonctions dites admin

Mais lorsque tu dois gérer des droits fonctionnels EDITABLES pour chaque user (par exemple droits lecture, ecriture, consultation et impression) il faut passer par java.

**vallica** · 21/04/2006, 09h46

Ok, la solution plus souple zekey est envisageable dans mon cas (pas plus de 15 actions normalement, et autant de forms/vues)

merci de m'avoir mis sur la voie à tous les 2

[Struts-Tiles] Pages à accès reservé

Struts 1 Java

Discussions similaires

Partager

Partager