Appeler un SLSB avec la sécurité de Seam à partir d'une servlet

Question

J'ai une application existante écrite en SEAM qui utilise SEAM Security (http://docs.jboss.org/seam/2.1.1.GA/reference/en-US/html/security.html). Dans un EJB sans état, je pourrais trouver quelque chose comme ceci :

@In
Identity identity;

... 

if(identity.hasRole("admin"))
  throw new AuthException();

D'après ce que j'ai compris, Seam injecte l'objet Identity depuis le SessionContext de la servlet qui invoque l'EJB (cela se passe "en coulisses", puisque Seam n'utilise pas vraiment les servlets) et le supprime après l'appel. Est-ce correct ?

Est-il maintenant possible d'accéder à cet EJB depuis une autre servlet (dans ce cas, cette servlet est le côté serveur d'une application GWT) ? Dois-je "injecter" la bonne instance d'Identity ? Si je ne fais rien, Seam injecte une instance, mais ne corrèle pas correctement les sessions et les instances d'Identity (ainsi les instances d'Identity sont partagées entre les sessions et parfois les appels obtiennent de nouvelles instances, etc.)

Toute aide et tout conseil sont les bienvenus - merci !

La technologie : EJB3, Seam 2.1.2. Les servlets sont en fait le côté serveur d'une application GWT, bien que je ne pense pas que cela importe beaucoup. J'utilise JBoss 5.

Answer 1

Seam injecte l'objet Identity depuis le SessionContext de la servlet qui invoque l'EJB et le supprime après l'appel. Est-ce correct ?

Oui, mais n'oubliez pas que vous doit activer l'intercepteur EJB Seam Voir aquí comment

...

Est-il maintenant possible d'accéder à n'importe quel EJB à partir d'une autre servlet ?

Oui, vous pouvez utiliser son JNDI global (dépendant du fournisseur) pour le récupérer. Voir aquí comment vous pouvez configurer et récupérer votre EJB @State less / ful bean. Si vous avez un entièrement -Vous pouvez le récupérer par le biais d'annotations.

Dois-je "injecter" la bonne instance d'identité ?

Vous n'avez pas à vous en préoccuper. L'intercepteur EJB de Seam s'en occupe. Allez-y.

UPDATE

mais dans l'EJB, deux instances différentes d'Identity sont injectées. Je suppose que le contexte de session que Seam utilise n'est pas correctement lié au contexte de session de la servlet ? Avez-vous une idée ?

Eh bien, le composant Identity lui-même n'implémente pas la méthode equals qui, par défaut, utilise l'implémentation equals par défaut en utilisant la comparaison equals (==). Je ne sais pas si, pour chaque appel EJB, vous avez toujours un nouveau composant Identity (cela explique peut-être pourquoi vous avez "deux instances différentes").

Si l'objet de votre Servlet partager Le même contexte vous pouvez activer IdentityFilter comme moyen d'envelopper votre rôle attribué à l'identité en utilisant la fonction isUserInRole méthode. Voici sa fonctionnalité :

Un filtre qui assure l'intégration entre Servlet Security et le composant d'identité Seam. Cette intégration est réalisée en enveloppant le HttpServletRequest avec une implémentation de HttpServletRequestWrapper. qui délègue les appels liés à la sécurité au composant d'identité Seam .

Si vous utilisez le composant @Identity, il est activé par défaut.

Ainsi, au lieu d'injecter votre EJB (et son @Identité @In-jectée) et d'utiliser

identity.hasRole("admin");

Vous pouvez utiliser

request.hasUserInRole("admin");

Et peut-être que vous voulez voir Réglage et lecture de l'ID de conversation Et Seam et GWT

Plus de

Le ContextFilter (non activé par défaut) ouvre l'accès au conteneur Seam et à ses variables contextuelles aux servlets non-JSF, tels que Struts, Spring MVC et Direct Web Remoting (DWR). Je ne sais pas comment utiliser ce type de fonctionnalité.

Answer 2

Votre question est incroyablement difficile à suivre et je ne suis pas sûr d'avoir tout compris. Quoi qu'il en soit, je suppose que vous utilisez les Stateless Session Beans (puisque vous avez dit Je pourrais utiliser des haricots à états ) qui, par définition, sont apatrides. Ainsi, comment Mary peut-elle s'authentifier en tant que Joe après un appel à un objet apatride session bean ? Ce n'est pas possible, ça n'a aucun sens.

PS : Vous devriez peut-être reformuler votre question et essayer de distinguer clairement des concepts tels que la session HTTP, les beans de session (sans état, avec état ?), SessionContext .