Index: topia/doc/SecuGestionPermission.rst
diff -u /dev/null topia/doc/SecuGestionPermission.rst:1.1
--- /dev/null	Fri May 20 17:51:15 2005
+++ topia/doc/SecuGestionPermission.rst	Fri May 20 17:51:10 2005
@@ -0,0 +1,14 @@
+====================================================
+Comment sont gérées les permissions au sein de ToPIA
+====================================================
+
+
+Les permissions sont nécessaires à deux endroits : dans le TopiaContext
+(sauvegarde des permissions) et dans le TopiaPolicy (gestion des permissions
+en cours d'éxécution). Cependant, afin d'éviter toute perte d'information,
+la moindre modification sur l'un des deux objets doit être répercutée sur
+l'autre. Pour cela, on considère que TopiaContext sera le poin d'entrée
+principal et le TopiaPolicy sera inscrit comme listener auprès du
+TopiaContext. Ainsi quand une permission sera ajoutée, modifiée ou
+supprimée, un évènement est envoyé au TopiaPolicy qui devrait donc effectuer
+la modification en question.

Index: topia/doc/WebSecu.rst
diff -u /dev/null topia/doc/WebSecu.rst:1.1
--- /dev/null	Fri May 20 17:51:15 2005
+++ topia/doc/WebSecu.rst	Fri May 20 17:51:10 2005
@@ -0,0 +1,66 @@
+============================================================
+Utilisation de la sécurité de ToPIA dans une application Web
+============================================================
+
+
+  La solution la plus simple revient à utiliser un filtre en implémentant
+l'interface Filter (javax.servlet.Filter). Ainsi, à chaque requête, le filtre
+vérifie la présence dans la session de l'instance de Subject
+(javax.security.auth.Subject) correspondant à l'utilisateur loggué. Si cet
+objet est présent, il laisse passer la requête en mettant l'instruction 
+chain.doFilter(...) dans un bloc Subject.doAs(...) pour que l'application 
+puisse ainsi récupérer l'instance courante de Subject sans avoir à s'occuper 
+de la session.
+Par contre, si l'objet n'est pas dans la session, cela signifie qu'aucun
+utilisateur n'est loggué, le filtre redirigera alors vers un page de login en
+prenant le soin de positionner en attribut de la requête l'URL demandée à
+l'origine. Ainsi, une fois l'utilisateur loggué, il est pourra être redirigé 
+vers la page qu'il souhaitait atteindre au départ.
+Pour certaines applications, on voudra connaitre le nom du module demandé, 
+le filtre est un endroit adéquate pour initialiser l'attribut dans la requête 
+puisqu'il constitue un passage obligatoire à toute requête.
+
+Le code suivant présente un exemple d'implémentation d'un tel filtre :
+
+
+public class TopiaSampleFilter implements javax.servlet.Filter {
+
+   public void init(FilterConfig arg0) throws ServletException { }
+
+   public void doFilter(ServletRequest req, ServletResponse resp, FilterChain ch)
+         throws IOException, ServletException {
+
+      final HttpServletRequest request = (HttpServletRequest) req;
+      final HttpServletResponse response = (HttpServletResponse) resp;
+      final FilterChain chain = ch;
+      HttpSession session = request.getSession();
+
+      String url = request.getAttribute(
+      "javax.servlet.forward.servlet_path").toString(); 
+      
+      Subject subject = (Subject) session.getAttribute("SUBJECT");
+      if (subject == null) {
+         request.setAttribute("REQUESTED_URL", url);
+         response.sendRedirect("logon.do");
+      } else {
+         String module = (String) request.getAttribute("MODULE_NAME");
+         if (module == null) {
+            module = url.replaceAll(".*?/(.*?)/.*", "$1");
+            request.setAttribute("MODULE_NAME", module);
+         }
+         Subject.doAs(subject, new PrivilegedAction() {
+            public Object run() {
+               try {
+                  chain.doFilter(request, response);
+               } catch (Exception e) {
+                  e.printStackTrace();
+               }
+               return null;
+            }
+         });
+      }
+   }
+
+   public void destroy() { }
+
+}