Flex+J2EE : Session timeout

Bonjour,

Je cherche à faire une redirection lorsque la session du côté serveur est invalide.
J'ai pensé à deux solutions :
1) Faire un filtre qui vérifie si la session est toujours valide
2) Intercepter l'erreur spécifique et faire la redirection adéquate grâce à une déclaration dans le web.xml

Bien que ne l'ayant pas testé, je pense que la solution 2 marchera. Mais je trouve la solution 1 plus propre.
Le problème de la solution 1 c'est que je suis incapable de faire la différence entre l'appel au service de login de l'utilisateur où la session est créée et les appels des autres services qui nécessitent une session valide puisque dans les deux cas ça passe par une adresse du style "/messagebroker" (config par défaut du plugin Flex pour Eclipse).

Avez-vous des recommandations ?

J'ai testé la solution 2.... sans succès car l'erreur n'est pas remontée, elle est transmise comme résultat de l'appel à un remoteObject (faultEvent).

La question est donc : peut-on se débrouiller pour faire une redirection depuis un service qui n'est qu'un simple bean gérer par Spring ?

Salut,

Tu veux rediriger l'utilisateur sur l'écran de login je suppose, pourquoi ne pas implémenter cela dans le handler d'erreur (FaultEvent ) ?

J'ai peut être mal compris ton besoin ;)

En effet, c'est une piste.

Mais j'aurai voulu quelque chose de plus global, car là ça suppose que je fasse le contrôle dans chaque handler d'erreur de mon appli.
En effet, 95% de mes services utilisent une variable en session pour le filtrage des données visibles par le profil de l'utilisateur courant.

C'est pour ça qu'une solution côté serveur uniquement me paraitrait plus adaptée, en espérant que ce soit possible :mrgreen:

Pour moi tu peux gérer ça avec un abstract delegate maison... avec un try catch par exemple sur tes appels à des remote object...

euh, je suis désolé mais j'ai pas trop compris ta solution Kantizbak :oops:

L'idée c'est que tu fais un appel avec ton remote object, il plante car la session est tombée ; à ce moment là tu refais un login en faisant un try/catch de l'appel au service
Tu fais une classe abstraite qui permet de faire ça qq soit le type de remote object et hop t'es tranquille ; j'ai fais ça et ça marche bien.

c'était pour répondre à ta remarque :

Citation:

---

ça suppose que je fasse le contrôle dans chaque handler d'erreur de mon appli.

---

pas besoin de le faire à chaque fois, suffit de mutualiser :mrgreen:

sinon remarque d'ordre général : à quoi sert de faire un client riche en flex si c'est pour conserver une variable en session côté serveur?
Autant faire un client html oueb1.0 :mrgreen:

Citation:

---

à ce moment là tu refais un login en faisant un try/catch de l'appel au service

---

Je refais un login moi-même, sans proposer la page adéquate à l'utilisateur ?

Et puis je dois pas être réveillé, mais par "try/catch de l'appel", tu entends ceci ? :

Code:

---

1 2 3 4 5 6 7

try{ monRemoteObject.maMethode(); } catch(e:Exception){ //gérer l'exception }

---

Oui quelque chose comme ça

Je ne compte pas te donner une solution complète tu comprendras, et puis ton cas est un peu particulier... l'idée c'est soit tu "reloggue" automatiquement ton utilisateur si tu veux réaliser une authent transparente (via flex ça peut poser des problèmes de sécu, je sais que par ntlm, l'authent de windows par exemple, c'est possible), soit tu modifie ta vue en affichant le login dans ton catch

bon c'est pas terrible en terme de conception de faire ça direct dans le catch :mrgreen: mais l'idée directrice pour moi c'est ça

si j'ai bien compris ton besoin évidemment :mrgreen:

J'ai pas tout compris de cette discussion mais il y a un truc qui me parait curieux.

Je ne crois pas que l'appel à une méthode d'un remoteObject déclenchera une erreur d'exécution. Si la session côté serveur n'est plus valide l'erreur sera renvoyée via un événement donc c'est pas au niveau du catch que tu peux gérer ça...

A moins que je n'ai rien compris du tout... :calim2:

Je suis d'accord avec jylaxx, je ne comprends pas comment ça peut marcher.

Sinon, toujours pour jylaxx, la discussion est de savoir comment faire pour réaliser une redirection lorsque la session côté serveur n'est plus valide.

Citation:

---

une redirection lorsque la session côté serveur n'est plus valide

---

J'utilise un serveur JAVA basé sur des sessions persistantes. Je pense que c'est l'un des intérêts d'une application Flex, pouvoir initialiser une session et conservée la même session tout au long de l'utilisation de l'application.

En plus j'utilise mon propre serveur basé sur la librairie Apache-MINA, et côté Flex j'utilise directement la classe Socket, donc j'ai peur de pas pouvoir t'aider davantage... :(

Citation:

---

Envoyé par jylaxx

J'ai pas tout compris de cette discussion mais il y a un truc qui me parait curieux.

Je ne crois pas que l'appel à une méthode d'un remoteObject déclenchera une erreur d'exécution. Si la session côté serveur n'est plus valide l'erreur sera renvoyée via un événement donc c'est pas au niveau du catch que tu peux gérer ça...

A moins que je n'ai rien compris du tout... :calim2:

---

Tout à fait c'est plutôt sur un faultEvent que tu peux le gérer ; pour l'idée c'est que tu ne peux savoir si la session est fermée côté serveur que lorsque tu fais un appel de service en te croyant authentifié... dans le cas où la session est fermée, tu récupère un fautEvent avec un message particulier, c'est ce cas que tu peux gérer partout...
à ce moment tu gère ta "redirection" ce qui en flex n'a pas de sens réel... il suffit de rappeler la vue de login

C'est ce que je pensais, mais devoir gérer ça partout....je ne suis pas sorti :aie:

d'ou l'idée d'avoir une classe abstraite qui gère de base les faultevent et dont tous tes delegate / remote object / commandes (ça dépend de ton architecture logicielle) vont hériter !

c'est une classe, 3 lignes dasn une méthode et une ligne supplémentaire dans tes faulthandler, pas la mer à boire ;)

Oui, sauf que j'ai eu la bonne idée d'appeler mes resultHandler d'une manière différente suivant la logique qu'il y a derrière et que parfois j'ai plusieurs handler dans mes commandes car plusieurs appels :mrgreen:

Mais ton idée est judicieuse et j'y penserai la prochaine fois !

Je viens de m'apercevoir qu'avec l'objet FlexContext, on pouvait récupérer les HttpServletRequest et HttpServletResponse. Finalement, il y aura peut-être moyen de faire un redirect "à l'ancienne" (enfin un rechargement de l'appli, pour que l'utilisateur se relogue).

Citation:

---

Envoyé par Fichman

Je viens de m'apercevoir qu'avec l'objet FlexContext, on pouvait récupérer les HttpServletRequest et HttpServletResponse. Finalement, il y aura peut-être moyen de faire un redirect "à l'ancienne" (enfin un rechargement de l'appli, pour que l'utilisateur se relogue).

---

Ouhlà ! bon je vais faire un peu le relou de service en terme de conception :

imaginons (bon ce n'est pas forcément la meilleure solution mais c'est un exemple) que tu tu gère ton application avec un viewStack, contenant deux vues : un panel de login et ton appli réelle, ce serait bien ne simplement switcher ta vue, non? ;)

le but du ria, c'est de ne pas recharger ton appli dès que tu n'es plus connecté !!! :mrgreen:

au contraire, tu dois "rediriger" au sein de ton appplication ;)

Comme je l'ai dit et comme le dit Kantizbak, niveau ergonomie recharger l'appli c'est un peu beaucoup bof :aie:, une simple redirection vers une vue interne à l'application est suffisante et ne permet pas à l'utilisateur d'avoir accès aux autres vue avant de s'être connecté (via authentification serveur). En plus, c'est tehcniquement beaucoup plus simple amha :mouarf:

Non mais je suis complétement d'accord.

Le problème c'est que récupérer côté client l'erreur spécifique de la session invalide m'oblige à modifier mon code à trop d'endroit.
Donc en attendant...

Bonsoir

L'idée, à mon avis est de créer une condition dans le fichier de base.

C'est lui seul qui doit vérifier si une session est en cours ou pas.
Et selon :
Soit basculer vers le formulaire d'identification
Soit basculer vers l'application

Puisque l'on parle de session (php je suppose ?), pourquoi ne pas gérer la session depuis le fichier principal index.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<?php session_start(); if ((!isset($_SESSION['bidule'])) && (empty($_SESSION['biduel']))) {   header('Location: identification.php'); // ou appel au fichier swf (identification login) // ou <div><object ... // ou include ... exit(); } else { // appel du fichier swf application de travail. // ou <div><object ... // ou include ... } ?>

---

Finalement, et à mon avis, c'est bcp plus simple de gérer les accés à la base de l'application, plutôt qu'en son sein.

Merci alain31tl de ta contribution mais je travaille en java côté serveur.
J'aurai dû le préciser... désolé.

Dans ton serveur Java, qu'est-ce que tu entends par session et qu'est-ce qui peut rendre une session invalide ?

Ben l'HttpSession qui peut être invalide à cause du timeout défini