RE : [sdx-users] Gestion dynamique de la sécurité

[Frédéric Glorieux]

On touche aux limites du modèle XSP.
Le mieux là serait peut-être d'agir au niveau du sitemap, par une
action.
La sitemap sdxtest donne un exemple en protégeant l'accès des vues
développeurs.

<map:act type="isAdmin">

L'action est ici une classe déjà compilée dans le jar sdx.
On peut faire de même avec des actions qui sont des xsp.

On explique un peu ici

http://wiki.cocoondev.org/Wiki.jsp?page=XSPAction

La taglib cocoon est plus longue à comprendre que le java qui le fait.
J'ai par exemple ce truc qui marche 

[sitemap]

<map:actions default="xsp">
  <map:action name="xsp" logger="sitemap.action.xsp"
src="org.apache.cocoon.acting.ServerPagesAction"/>
</map:actions>

<map:act type="xsp" src="action.xsp">
  <map:parameter name="driver" value="org.gjt.mm.mysql.Driver"/>
  <map:parameter name="url" value="jdbc:mysql://localhost/ecfa"/>
  <map:parameter name="userid" value=""/>
  <map:parameter name="password" value=""/>
  <map:match="" ....

[action.xsp]
<?xml version="1.0"?>
<xsp:page language="java"
xmlns:action="http://apache.org/cocoon/action/1.0";
xmlns:xsp="http://apache.org/xsp";>
    <xsp:structure>
        <xsp:include>org.apache.cocoon.environment.Session</xsp:include>
    </xsp:structure>
    <!--
    This xsp action use cocoon taglib action.xsl to get some context,
    action.xsl is not used for inline tags (less easier than a simple
java line)
        
        His only work is to make available his sitemap params to sub
sitemap component,
        accessible as ../paramName (or ../../paramName ....)
-->

    <view>
        <xsp:logic>
/* goal, pass parameters to the sub components of  */
                
    try {
                String[] names=parameters.getNames();
                try { 
                        for (int i=0; i &lt; names.length; i++)
                        {
                                this.actionResultMap.put(names[i],
parameters.getParameter(names[i]));
                        }
                }
                catch (Exception e) {this.actionResultMap.put("error",
e); }
                // list of params ?
                
                
                // failure could be possible to handle (example:
properties undefined ?) -->
        if (true)
this.objectModel.put(ServerPagesAction.ACTION_SUCCESS_OBJECT,
Boolean.TRUE);
        else
this.objectModel.put(ServerPagesAction.ACTION_SUCCESS_OBJECT,
Boolean.FALSE);
    } 
    catch (Exception e)
{this.objectModel.put(ServerPagesAction.ACTION_SUCCESS_OBJECT,
Boolean.FALSE);}
  </xsp:logic>
    </view>
</xsp:page>


C'est un contournement peu élégant en attendant les variables globales
de Cocoon 2.1
Avec ce principe, on peut faire des tests, échec/réussite de l'action
(pour la gestion de droit cela interdit complètement l'accès aux
pipelines inclus), ou en moins méchant, fixer un paramètre isAdmin au
passage, que les xsp attrappent pour définir ce qu'elles affichent.

A mon avis, une telle xsp pourrait bien se faire avec la taglib sdx
(<isAdmin/>)


Pour l'opération demandée plus bas, il ne s'agit pas vraiment d'un
include, mais d'une transformation avant la transformation/compilation
xsp.

Il se peut qu'un 
<xsp:logicsheet  /> puisse aider (mais je ne suis plus sûr de l'attribut
pour spécifier le chemin, ni de l'ordre du process)

> -----Message d'origine-----
> De : address@hidden 
> [mailto:address@hidden
> rg] De la part de Pierre Dittgen
> Envoyé : mercredi 2 juillet 2003 15:29
> À : address@hidden
> Objet : [sdx-users] Gestion dynamique de la sécurité
> 
> 
> Bonjour,
> 
> Je suis en train de travailler sur une application SDX qui demande à 
> l'utilisateur d'être authentifié. J'utilise des éléments 
> sdx:userIsMember pour vérifier l'identité de l'utilisateur et code le 
> nom des groupes en utilisant le mode Java de passage de paramètres :
> 
>       <xsp:logic>
>               String[] myGroups = new String[]{"admins","consultant"};
>       </xsp:logic>
>       <sdx:userIsMember groupStrings="myGroups" op="or">
>               [...]
>               <sdx:fallback>
>                       [...]
>               </sdx:fallback>
>       </sdx:userIsMember>
> 
> Je n'ai pas envie de placer ce code dans toutes mes XSP car 
> si le nom ou 
> le nombre de mes groupes autorisés change, je devrai le modifier dans 
> toutes les XSP.
> 
> J'ai plutôt placé un élément 
> <authentication></authentication> dans mes 
> XSP et j'ai créé une feuille XSL (authentication.xsl) qui me remplace 
> cet élément authentication par le code montré + haut et ne 
> modifie pas 
> les autres éléments.
> Ainsi, si mes groupes changent, je ne le change qu'à un seul 
> endroit : 
> dans ma feuille XSL.
> 
> Tant que j'y suis, j'ai créé une feuille noauthentication.xsl qui 
> supprime le tag <authentication></authentication> en 
> conservant tous les 
> autres.
> 
> Maintenant, je souhaiterai pouvoir choisir le mode de mon application 
> "authentification obligatoire" ou "pas d'authentification" en 
> manipulant 
>   uniquement les pipelines définis dans mon fichier sitemap.xmap.
> 
> Naïvement, j'ai testé :
>           <map:match pattern="*.xsp">
>              <map:generate type="xsp" src="{1}.xsp"/>
>              <map:transform src="xsl/authentication.xsl"/>
>              <map:transform type="cinclude"/>
>              <map:transform src="xsl/{1}.xsl">
>                 <map:parameter name="use-request-parameters" 
> value="true"/>
>              </map:transform>
>              <map:serialize/>
>           </map:match>
> 
> Mais ça ne fonctionne pas car le traitement des tags XSP et 
> SDX se fait 
> avec la ligne <map:generate type="xsp" .../> et ma XSL arrive 
> trop tard. 
> Est-il possible "découper" la ligne <map:generate> en 2 opération 
> distinctes : lecture du fichier et traitement du fichier, je pourrai 
> alors insérer ma feuille entre les deux...
> 
> Merci pour vos idées
> Pierre
> -- 
> Pierre Dittgen, address@hidden
> PASS Technologie http://www.pass-tech.fr
> 
> 
> 
> 
> 
> _______________________________________________
> sdx-users mailing list
> address@hidden http://mail.nongnu.org/mailman/listinfo/sdx-users
>