Discussion :

[Anonymouse]

Bonjour

Je redéfinis la méthode "processRoles" de "RequestProcessor" pour vérifier que mon utilisateur est authentifié.

Si l'user n'est pas loggé je redirige vers une page d'erreur content le tag: "<html:errors/>".

Il est mentionné, dans la FAQ, la possibilité de créer des objets "ActionErrors". Mais je ne vois pas comment les stocker pour les transmettre à la JSP.

Dois-je les enregistrer dans la request pour les transmettre à mon contrôleur d'erreur qui pourrait les ajouter? Ou existe t-il une manière plus simple pour, à partir du "RequestProcessor", les sauvegarder?

Merci d'avance de vos réponses

[cocula]

Bonjour,

Je ne vais pas répondre dans un premier temps à ta question mais faire quelques critiques.

Je trouve dommage de renvoyer l'utilisateur sur une page d'erreur. Est-ce le comportement de la plupart des applications ? non. En général, si l'utilisateur n'est pas connecté, on le redirige vers la page de login. C'est tout de même plus positif pour l'utilisateur de "l'inviter" à entrer que de lui fermer la porte au nez.

[Anonymouse]

Bonjour,

Je ne vais pas répondre dans un premier temps à ta question mais faire quelques critiques.

Je trouve dommage de renvoyer l'utilisateur sur une page d'erreur. Est-ce le comportement de la plupart des applications ? non. En général, si l'utilisateur n'est pas connecté, on le redirige vers la page de login. C'est tout de même plus positif pour l'utilisateur de "l'inviter" à entrer que de lui fermer la porte au nez.

Mon utilisateur ne se connecte pas à mon appli il se connecte à l'intranet qui appellera automatiquement ma page de login en lui passant les bonnes infos.

Par conséquence si l'utilisateur n'a pas accès à mon appli c'est qu'il n'a pas les droits pour se connecter.

[cocula]

Dans ce cas, c'est il s'agit d'une exception et non d'une erreur.

Je m'explique :

Si ton utilisateur est entré sur une des pages de ton appli c'est que l'intranet lui en a donné la possibilité. Il est de la responsabilité de l'intranet d'authentifer ton utilisateur ou de ne pas lui montrer le lien vers ton appli si celui ci n'y est pas autorisé. Donc, si on accède à l'appli est que l'on est pas authentifié, c'est un cas d'exception à traiter comme tel, c'est à dire en renvoyant ServletException.

J'ai déjà fait ce genre de truc en intégrant une appli dans un portail JSR168.

Bon, si vraiment, tu comptes afficher une page d'erreur, je ne vois pas l'utilité de placer en request des ActionErrors. Les ActionErrors doivent être manipulées par les action (comme leur nom l'indique) dans la philosophie de Struts. Elles servent surtout à distinguer les notions d'erreurs globales et d'erreurs associées à une propriété du formulaire.
Dans ton cas, il suffit de rediriger l'utilisateur sur une bête page qui affiche un message à l'aide d'un <bean:message>.

Autre question : pourquoi choisir de surcharger la méthode processRoles pour s'assurer que l'utilisateur est bien authentifié ?
En effet, il serait peut être plus judicieux de surcharger processActionPerform qui renvoie un ActionForward afin que ce forward soit vraiment traiter par la suite.
processRoles ne fait que générer une erreur HTTP ce qui est en contradiction avec ton besoin de montrer une page à toi.

Enfin je ne suis même pas certain que c'est dans le requestProcessor que tu as intérêt à effectuer le contrôle. Est-ce que ce ne serait pas mieux en intercalant un filtre de servlet dans le cas où ton appli est appelée dans le cadre de ton intranet. Ce qui permettrait éventuellement deux comportements différents selon que ton appli fonctionne en mode autonome ou en mode intranet.

En surchargeant le requestProcessor, il faut bien penser que tu va être emmerdé si tu upgrade Struts.

[Anonymouse]

Dans ce cas, c'est il s'agit d'une exception et non d'une erreur.

Je m'explique :

Si ton utilisateur est entré sur une des pages de ton appli c'est que l'intranet lui en a donné la possibilité. Il est de la responsabilité de l'intranet d'authentifer ton utilisateur ou de ne pas lui montrer le lien vers ton appli si celui ci n'y est pas autorisé. Donc, si on accède à l'appli est que l'on est pas authentifié, c'est un cas d'exception à traiter comme tel, c'est à dire en renvoyant ServletException.

J'ai déjà fait ce genre de truc en intégrant une appli dans un portail JSR168.

Bon, si vraiment, tu comptes afficher une page d'erreur, je ne vois pas l'utilité de placer en request des ActionErrors. Les ActionErrors doivent être manipulées par les action (comme leur nom l'indique) dans la philosophie de Struts. Elles servent surtout à distinguer les notions d'erreurs globales et d'erreurs associées à une propriété du formulaire.
Dans ton cas, il suffit de rediriger l'utilisateur sur une bête page qui affiche un message à l'aide d'un <bean:message>.

Autre question : pourquoi choisir de surcharger la méthode processRoles pour s'assurer que l'utilisateur est bien authentifié ?
En effet, il serait peut être plus judicieux de surcharger processActionPerform qui renvoie un ActionForward afin que ce forward soit vraiment traiter par la suite.
processRoles ne fait que générer une erreur HTTP ce qui est en contradiction avec ton besoin de montrer une page à toi.

Enfin je ne suis même pas certain que c'est dans le requestProcessor que tu as intérêt à effectuer le contrôle. Est-ce que ce ne serait pas mieux en intercalant un filtre de servlet dans le cas où ton appli est appelée dans le cadre de ton intranet. Ce qui permettrait éventuellement deux comportements différents selon que ton appli fonctionne en mode autonome ou en mode intranet.

En surchargeant le requestProcessor, il faut bien penser que tu va être emmerdé si tu upgrade Struts.

L'intranet affiche les bons liens selon le rôle de la personne. Je veux juste gérer les cas ou un petit malin appelle directement mon application .

Je suis débutant en struts et en JEE, j'ai donc suivit la FAQ qui recommande de faire le test d'authentification dans le requestProcessor. Si je comprend bien le concept, si la personne ne peut se connecter, mon filtre la redirigera vers une page d'erreur. Je verrai comment implémenter le filtre se soir (je n'ai pas mon bouquin sous la main).

En déviant du sujet pour revenir au concept d'exception dans struts. J'ai jusqu'ici deux types d'erreurs provoquées par ma DAO (type personnalisé DaoException).

-Les erreurs que je ne peux réparer: Je les catch dans les sous-contrôleurs "Action", les stocks dans un ActionErrors et affiche une page d'erreurs spéciale (<html:errors/>) qui contient un message pour l'user.
-Les erreurs non importantes (Ex: je n'ai pas pu récupérer une valeur accessoire dans la DAO): je les affiches comme informations pour mon utilisateur avec (<html:errors/>).

En suivant la philosophie struts, je dois, pour toute mes erreurs irrécupérables, associer une jsp spécialisée?

[cocula]

-Les erreurs que je ne peux réparer: Je les catch dans les sous-contrôleurs "Action", les stocks dans un ActionErrors et affiche une page d'erreurs spéciale (<html:errors/>) qui contient un message pour l'user.

Il faut renvoyer plutôt une servletException.

-Les erreurs non importantes (Ex: je n'ai pas pu récupérer une valeur accessoire dans la DAO): je les affiches comme informations pour mon utilisateur avec (<html:errors/>).

Attention : ne pas confondre "erreurs non importantes" et exceptions. Ce que tu appelle "erreurs non importantes" est en réalité de la logique métier (ie: un objet est plus ou moins complet). Il s'agit de renvoyer des erreurs appropriées à l'utilisateur. Les execptions (même dans ton DAO sont réservées aux véritables cas de de plantages).

[Anonymouse]

Il faut renvoyer plutôt une servletException.



Attention : ne pas confondre "erreurs non importantes" et exceptions. Ce que tu appelle "erreurs non importantes" est en réalité de la logique métier (ie: un objet est plus ou moins complet). Il s'agit de renvoyer des erreurs appropriées à l'utilisateur. Les execptions (même dans ton DAO sont réservées aux véritables cas de de plantages).

-Et comment est ce que je fais pour gérer les servletException? Dois-je utiliser les balises struts

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<global-exceptions> et <exception>

dans le struts-conf ou simplement redéfinir la page d'erreur 500.

Pour le deuxième point je stocke actuellement les message non critiques dans mes objets métiers pour les afficher si nécessaire.

Je suis désolé de t'assommer de toute mes questions, mais je n'ai point trouvé de cours sérieux capable d'y répondre.

Merci de tes réponses,

[cocula]

-Et comment est ce que je fais pour gérer les servletException? Dois-je utiliser les balises struts

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<global-exceptions> et <exception>

dans le struts-conf ou simplement redéfinir la page d'erreur 500.

Je ne connais pas cette fonctionnalité, je ne m'en suis jamais servi.

Pour le deuxième point je stocke actuellement les message non critiques dans mes objets métiers pour les afficher si nécessaire.

Pour moi, un objet métier ne contient pas de message quelconque. C'est l'appel du service qui te fournit l'objet métier qui doit éventuellement accompagner son résultat d'un certain nombre de messages.

[Anonymouse]

Je ne connais pas cette fonctionnalité, je ne m'en suis jamais servi.

Pour moi, un objet métier ne contient pas de message quelconque. C'est l'appel du service qui te fournit l'objet métier qui doit éventuellement accompagner son résultat d'un certain nombre de messages.

La DAO me retourne une liste d'objets employés. J'affiche le premier dans une page JSP. Si l'un des attributs de l'objet courant n'a pu être remplis. Je ne peux afficher les problèmes d'initialisation des autres objets si l'utilisateur ne s'en sert pas. Il me faut donc stocker les erreurs d'initialisation pour les afficher lorsque le bon employé sera sélectionné.
Si tu as une autre solution, je suis preneur.