Je viens de publier mon premier article dans le blog JDuchess.
J'ai fait un pré compte rendu qui introduit le speaker Adam Bien ainsi que les sujets qui seront présentés en détail lors de la conférence du dernier JUG avant la rentrée.
Adam nous promet d'illustrer sa présentation par des exemples pratiques.
Voici le lien :
Merci Claude Falguière, Laurent Guérin et Julien Maupoux pour vos relectures, corrections et conseils sur la mise en forme.
mercredi 30 juin 2010
mardi 15 juin 2010
Tapestry 5.1 et Spring Security
Voici comment marche la configuration de Spring Security avec Tapestry 5.1.
Cas d'utilisation :
- L'autorisation par formulaire (par la validation utilisateur / mot de passe)
- Mode connecté / anonyme
- Accès interdit sur les pages d'administration
Il nous faut avoir quatre pages Tapestry :
Configuration "web.xml"
Pour habiliter Spring et Spring Security, il faut d'abord configurer le fichier web.xml pour y placer les filtres. Tapestry, contrairement à Struts, est une framework configuré par un filtre; il faut faire attention donc à l'ordre sur le fichier ; le filtre de spring security doit se trouver en premier lieu.
<context-param>
<param-name>tapestry.app-package</param-name>
<param-value>com.tapestwitter</param-value>
</context-param>
<context-param>
<param-name>tapestry.use-external-spring-context</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath*:applicationContext*.xml</param-value>
</context-param>
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>
org.springframework.web.filter.DelegatingFilterProxy
</filter-class>
</filter>
<filter>
<filter-name>tapesTwitter</filter-name>
<filter-class>
org.apache.tapestry5.spring.TapestrySpringFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>tapesTwitter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Configuration du fichier "applicationContextSecurity.xml "
La version 3 de Spring permet de décharger la configuration XML en utilisant le "security namespace".
Contenu du fichier de configuration de spring security
contenu du fichier de beans de spring
Security.properties
Dans le module tapestry de l'application, dans le code source d'exemple fourni par la classe TapesTwitterModule.java, on peut contribuer aux symbols de l'IoC pour permettre d'injecter les valeurs du fichier security.properties à l'aide de l'annotation @Symbol.
Contenu Login.java
Contenu Login.tml
<form action="${loginUrl}" method="post">
<t:if test="error">
<p>
${message:login.error}
</p>
</t:if>
<fieldset>
<label for="j_username">${message:label-username}</label>
<input class="username" id="j_username" name="j_username" type="text" maxlength="30" value=""/><
<label for="j_password">${message:label-password}</label>
<input class="password" id="j_password" name="j_password" type="password" maxlength="30" value="" />
<input type="checkbox" name="j_spring_security_remember_me" id="remember_me"/>
<label class="inline" for="remember_me">${message:text-rememberme}</label></td>
<input id="login_submit" class="btn" type="submit" value="${message:button-login}" name="commit"/></td>
</fieldset>
</form>
Comment cela fonctionne ?
Lorsque l'utilisateur clique sur le bouton du login, Tapestry appellera l'URL "j_spring_security_check".
Spring prend la main sur l'application.
Spring security appelle le "Spring Security Filter Chain" - la chaine de filtres de connexion.
Grâce aux beans que l'on a développés (l'interface UserDetails, UserManagerImpl, UserDetailsServiceImpl etc.), Spring est capable de connecter l'utilisateur.
Si la connexion se déroule correctement, Spring Security redirigera vers l'url "/login" qui activera la page "Login". Ensuite Tapestry reprend la main!
L'événement "ACTIVATE" est lancé par Tapestry et capturé par la méthode "checkSecurityCtx".
Celle-ci vérifie la bonne connexion avec le bean "securityContext" pour ensuite rediriger vers la page "Home".
Si la connexion échoue, Spring Security redirigera vers l'url "/login/error" qui activera aussi la page de Login du Tapestry ! Mais un peu différemment : elle est activée avec "un paramétre" dans le contexte : "error". Dans l'URL, Tapestry détectera que la partie "login" est la page et "error" est la valeur d'un paramètre du contexte d'activation de la page.
Ainsi, la méthode qui est exécutée est "checkError(String extra)", extra = "error", pour ensuite rediriger vers la page de Login (return null affiche la page courante, la page de login) et afficher le message d'erreur attendu.
Pour plus d'information sur la partie Spring Security
Télécharger le code source depuis : tapestwitter 2.0
Cas d'utilisation :
- L'autorisation par formulaire (par la validation utilisateur / mot de passe)
- Mode connecté / anonyme
- Accès interdit sur les pages d'administration
Il nous faut avoir quatre pages Tapestry :
- page d'accueil aux utilisateurs non connectés - Index.tml + Index.java
- page d'accueil aux utilisateurs connectés - Home.tml + Home.java
- page de connexion au site - Login.tml + Login.java
- page pour les administrateurs - Admin.tml + Admin.java
Configuration "web.xml"
Pour habiliter Spring et Spring Security, il faut d'abord configurer le fichier web.xml pour y placer les filtres. Tapestry, contrairement à Struts, est une framework configuré par un filtre; il faut faire attention donc à l'ordre sur le fichier ; le filtre de spring security doit se trouver en premier lieu.
<context-param>
<param-name>tapestry.app-package</param-name>
<param-value>com.tapestwitter</param-value>
</context-param>
<context-param>
<param-name>tapestry.use-external-spring-context</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath*:applicationContext*.xml</param-value>
</context-param>
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>
org.springframework.web.filter.DelegatingFilterProxy
</filter-class>
</filter>
<filter>
<filter-name>tapesTwitter</filter-name>
<filter-class>
org.apache.tapestry5.spring.TapestrySpringFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>tapesTwitter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Configuration du fichier "applicationContextSecurity.xml "
La version 3 de Spring permet de décharger la configuration XML en utilisant le "security namespace".
Contenu du fichier de configuration de spring security
<http auto-config="true" use-expressions="true">
<intercept-url pattern="/admin/**" access="hasRole('ROLE_ADMIN')"/>
<intercept-url pattern="/index*" access="permitAll" />
<intercept-url pattern="/login*" access="permitAll" />
<intercept-url pattern="/login/error*" access="permitAll" />
<intercept-url pattern="/assets/**" access="permitAll"/>
<intercept-url pattern="/home**"
access="isAuthenticated() or isRememberMe()" />
<intercept-url pattern="/**" access="permitAll"/>
<form-login login-page="${loginFormUrl}"
authentication-failure-url="${authenticationFailureUrl}"
default-target-url="${defaultTargetUrl}"
always-use-default-target="false"/>
<anonymous />
<remember-me key="tapestwitter"/>
<logout />
</http>
<authentication-manager alias="authenticationManager">
<authentication-provider ref="tapestwitterAuthenticationProvider"/>
</authentication-manager>
contenu du fichier de beans de spring
<bean id="tapestwitterPasswordEncoder"
class="org.springframework.security.authentication.encoding.ShaPasswordEncoder" />
<bean id="tapestwitterSaltSource"
class="org.springframework.security.authentication.dao.SystemWideSaltSource">
<property name="systemWideSalt" value="tapestwitttertwit" />
</bean>
<bean id="tapestwitterSecurityContext"
class="com.tapestwitter.domain.security.impl.TapestwitterSecurityContextImpl"/>
<bean id="userManager" class="com.tapestwitter.domain.business.impl.UserManagerImpl">
<property name="securityContext" ref="tapestwitterSecurityContext" />
<property name="saltSource" ref="tapestwitterSaltSource"/>
<property name="passwordEncoder" ref="tapestwitterPasswordEncoder"/>
</bean>
<bean id="tapestwitterUserDetailService"
class="com.tapestwitter.domain.security.impl.UserDetailsServiceImpl">
<constructor-arg ref="userManager" />
</bean>
<bean id="tapestwitterAuthenticationProvider"
class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
<property name="userDetailsService" ref="tapestwitterUserDetailService"/>
<property name="saltSource" ref="tapestwitterSaltSource"/>
<property name="passwordEncoder" ref="tapestwitterPasswordEncoder"/>
</bean>
Security.properties
loginSecurityFilterUrl=/j_spring_security_checkCharger les propriétés de Spring Security sur Tapestry
logoutSecurityFilterUrl=/j_spring_security_logout
loginFormUrl=/login
logoutTargetUrl=/index
defaultTargetUrl=/homepage
authenticationFailureUrl=/login/error
Dans le module tapestry de l'application, dans le code source d'exemple fourni par la classe TapesTwitterModule.java, on peut contribuer aux symbols de l'IoC pour permettre d'injecter les valeurs du fichier security.properties à l'aide de l'annotation @Symbol.
Page Login
public static void contributeSymbolSource(OrderedConfiguration<SymbolProvider> providers)
{
providers.add("springSecurity",
new ClasspathResourceSymbolProvider("config/security.properties"));
}
Contenu Login.java
public class Login
{
@Inject
@Symbol("loginSecurityFilterUrl")
private String loginUrl;
@Inject
private TapestwitterSecurityContext securityContext;
private boolean error;
@OnEvent(value = EventConstants.ACTIVATE)
public Object checkSecurityCtx()
{
if (securityContext.isLoggedIn())
{
return HomePage.class;
}
return null;
}
@OnEvent(value = EventConstants.ACTIVATE)
public void checkError(String extra)
{
if (extra.equals("error"))
{
error = true;
}
}
public String getLoginUrl()
{
return loginUrl;
}
public boolean isError()
{
return error;
}
}
Contenu Login.tml
<form action="${loginUrl}" method="post">
<t:if test="error">
<p>
${message:login.error}
</p>
</t:if>
<fieldset>
<label for="j_username">${message:label-username}</label>
<input class="username" id="j_username" name="j_username" type="text" maxlength="30" value=""/><
<label for="j_password">${message:label-password}</label>
<input class="password" id="j_password" name="j_password" type="password" maxlength="30" value="" />
<input type="checkbox" name="j_spring_security_remember_me" id="remember_me"/>
<label class="inline" for="remember_me">${message:text-rememberme}</label></td>
<input id="login_submit" class="btn" type="submit" value="${message:button-login}" name="commit"/></td>
</fieldset>
</form>
Comment cela fonctionne ?
Lorsque l'utilisateur clique sur le bouton du login, Tapestry appellera l'URL "j_spring_security_check".
Spring prend la main sur l'application.
Spring security appelle le "Spring Security Filter Chain" - la chaine de filtres de connexion.
Grâce aux beans que l'on a développés (l'interface UserDetails, UserManagerImpl, UserDetailsServiceImpl etc.), Spring est capable de connecter l'utilisateur.
Si la connexion se déroule correctement, Spring Security redirigera vers l'url "/login" qui activera la page "Login". Ensuite Tapestry reprend la main!
L'événement "ACTIVATE" est lancé par Tapestry et capturé par la méthode "checkSecurityCtx".
Celle-ci vérifie la bonne connexion avec le bean "securityContext" pour ensuite rediriger vers la page "Home".
Si la connexion échoue, Spring Security redirigera vers l'url "/login/error" qui activera aussi la page de Login du Tapestry ! Mais un peu différemment : elle est activée avec "un paramétre" dans le contexte : "error". Dans l'URL, Tapestry détectera que la partie "login" est la page et "error" est la valeur d'un paramètre du contexte d'activation de la page.
Ainsi, la méthode qui est exécutée est "checkError(String extra)", extra = "error", pour ensuite rediriger vers la page de Login (return null affiche la page courante, la page de login) et afficher le message d'erreur attendu.
Pour plus d'information sur la partie Spring Security
Télécharger le code source depuis : tapestwitter 2.0
mardi 18 mai 2010
Maven 3
Maven 3 est encore dans sa version bêta, mais il promet ! Au Paris JUG, Arnaud Heritier et Nicolas De Loof nous l'ont présenté. Voici mes retours !
Migrons à Maven 3 !
Est-il facile à migrer ?
Il suffit de changer votre version de maven ! Et voilà, c'est fini !
Est-il compatible avec les versions précédentes ?
Oui, la compatibilité est assurée à un 99,99%
Les exceptions qu'on peut trouver sont par rapport aux descripteurs de projet qui sont encore beaucoup plus stricts que dans ses versions précédentes, ainsi que le Maven Site ou la commande eclipse:eclipse qui sont en phase de correction.
Les développements de cette version ont été focalisés pour assurer la compatibilité descendante, affirmation avalisée par les efforts en développement des tests unitaires.
Cette nouvelle version est en effet une refonte complète. Elle se caractérise par les retours d'expérience et l'apprentissage que ses concepteurs et développeurs ont obtenu à partir des versions 1 et 2.
La version 1 de Maven était inmaintenable ; la version 2 était plus maintenable et incluait le support de plugins. L'architecture était améliorée, mais encore pas très extensible et elle manquait de souplesse rendant très compliqué (parfois quasiment impossible) d'entrer dans le code.
Nouveautés :
> Java 5
Et tous les avantages qui vont avec, les generics par exemple. Le code source est plus propre, et la documentation a été nettement améliorée, essentiellement pour bien distinguer les API publics des internes. Grâce à tout cela, le développement des nouveax plugins et fonctionnalités est rendu plus accessible.
> Plugins interactifs
Les plugins restent toujours indépendants, mais ils sont capables de s'adapter au contexte d'exécution, ce qui est traduit par la disparition du plugin Aggregator et la naissance de "Build Plan". On pourra, par exemple, lister les tests à exécuter à l'avance. Cela évitera de les passer plusieurs fois, contrairement à aujourd'hui où les plugins ne savent pas quels sont les tests qui ont été déjà joués.
> Rencontre OSGi
L'outil Tycho est une sorte de portage de Maven 2 pour les applications basées sur OSGi. Eclipse est basé sur un modèle OSGi. Maven 3 inclut Tycho, ce qui permet leur meilleure intégration. Le plugin M2Eclipse s'appuie sur Tycho.
> L'intégration avec eclipse
Maven 2 permettait seulement de réaliser des builds complets. Maven 3 permettra de laisser à eclipse l'ensemble des étapes qu'il sait faire, la compilation par exemple, et de réaliser en maven ce qui reste. Le plugin d'eclipse retirera les tâches du "build plan" évitant ainsi tout conflit.
> Pom Polyglotte
Maven 3 permettra d'écrire le fichier pom.xml en Groovy ou Python par exemple, en plus de XML.
Prochainement :
Ce n'est pas pour les nouvelles fonctionnalités que cette version apporte - on constate que n'il y en a pas trop encore - mais plutôt pour les raisons suivantes :
Apache Maven de Pearson, écrit par les deux speakers !
http://www.pearson.fr/livre/?GCOI=27440100730370
Lancez-vous, migrez !
Migrons à Maven 3 !
Est-il facile à migrer ?
Il suffit de changer votre version de maven ! Et voilà, c'est fini !
Est-il compatible avec les versions précédentes ?
Oui, la compatibilité est assurée à un 99,99%
Les exceptions qu'on peut trouver sont par rapport aux descripteurs de projet qui sont encore beaucoup plus stricts que dans ses versions précédentes, ainsi que le Maven Site ou la commande eclipse:eclipse qui sont en phase de correction.
Les développements de cette version ont été focalisés pour assurer la compatibilité descendante, affirmation avalisée par les efforts en développement des tests unitaires.
Cette nouvelle version est en effet une refonte complète. Elle se caractérise par les retours d'expérience et l'apprentissage que ses concepteurs et développeurs ont obtenu à partir des versions 1 et 2.
La version 1 de Maven était inmaintenable ; la version 2 était plus maintenable et incluait le support de plugins. L'architecture était améliorée, mais encore pas très extensible et elle manquait de souplesse rendant très compliqué (parfois quasiment impossible) d'entrer dans le code.
Nouveautés :
> Java 5
Et tous les avantages qui vont avec, les generics par exemple. Le code source est plus propre, et la documentation a été nettement améliorée, essentiellement pour bien distinguer les API publics des internes. Grâce à tout cela, le développement des nouveax plugins et fonctionnalités est rendu plus accessible.
> Plugins interactifs
Les plugins restent toujours indépendants, mais ils sont capables de s'adapter au contexte d'exécution, ce qui est traduit par la disparition du plugin Aggregator et la naissance de "Build Plan". On pourra, par exemple, lister les tests à exécuter à l'avance. Cela évitera de les passer plusieurs fois, contrairement à aujourd'hui où les plugins ne savent pas quels sont les tests qui ont été déjà joués.
En conséquence, le plugin Aggregator ne devra plus jamais être utilisé.
> Rencontre OSGi
L'outil Tycho est une sorte de portage de Maven 2 pour les applications basées sur OSGi. Eclipse est basé sur un modèle OSGi. Maven 3 inclut Tycho, ce qui permet leur meilleure intégration. Le plugin M2Eclipse s'appuie sur Tycho.
> L'intégration avec eclipse
Maven 2 permettait seulement de réaliser des builds complets. Maven 3 permettra de laisser à eclipse l'ensemble des étapes qu'il sait faire, la compilation par exemple, et de réaliser en maven ce qui reste. Le plugin d'eclipse retirera les tâches du "build plan" évitant ainsi tout conflit.
> Pom Polyglotte
Maven 3 permettra d'écrire le fichier pom.xml en Groovy ou Python par exemple, en plus de XML.
Prochainement :
- L'équipe maven vise à remplacer le conteneur Plexus par Google Guice ou Spring. Rien n'a encore été décidé.
- Éliminer la maintenance du nom de version sur le POM
- Mixins : Permettront de faire un héritage multiple mais pas forcement hiérarchique
- Évolution de la syntaxe : permettra, par exemple, de définir des exclusions globales et pas seulement au niveau de chaque dépendance
- Parallélisation des builds : permettra aux grosses applications multimodule de paralléliser les builds de ses modules indépendants en gagnant du temps de manière significative.
- Maven Shell
Ce n'est pas pour les nouvelles fonctionnalités que cette version apporte - on constate que n'il y en a pas trop encore - mais plutôt pour les raisons suivantes :
- Maven 3 est plus performant
- Les logs, en cas d'erreur, sont plus lisibles
- Le reporting est amélioré
- La communauté est mature et expérimentée. Nous comptons sur un grand nombre de développeurs et utilisateurs senior. De plus, la version 3 a attiré l'attention des nouveaux développeurs, ce qui a fait revivre le projet.
Apache Maven de Pearson, écrit par les deux speakers !
http://www.pearson.fr/livre/?GCOI=27440100730370
Lancez-vous, migrez !
Inscription à :
Articles (Atom)