En fait, mon problème est unique, et vous avez deux manières de pouvoir m'aider... C'est chouette, hein ?    
 
Bon alors voilà : je développe un site intranet qui va piocher des données dans une base de données, et je dois utiliser java et ses servelts. Débutant en java, j'ai réussi à faire avancer un peu le problème. Mais là je bloque : je dois authentifier des utilisateurs. Et pour ce faire, je suis parti de l'idée suivante :
 
Je vérifie un couple user/pwd dans une base de données. Si c'est invalide, bien évidemment ca ne marche pas. Si cela est OK, je lui crée une session. Donc  si l'utilisateur a une session, c'est qu'il est identifié.
 
Le problème est qu'il faut qu'a chaque page, on vérifie qu'il s'agisse bien du bon utilsateur (tous n'ont pas accès aux memes pages), et que la  session n'a pas expirée.
 
Donc voici comment je procède : il passe par une page d'authentification qui lui donne un id session, et le stocke dans un cookie.
A chaque consultation de page, je cherche le cookie, je le compare avec ce qu'a le serveur en mémoire, et si ce n'est pas égal => dehors.
 
Et mon "prb" : cela fait beaucoup de code au début de chaque page : je souhaite donc "externaliser" la tache de début de page.
Et donc mon code "souhaité" serait le suivant :

 
Et je n'arrrive pas à récuperer ce boolen de ma page externe... J'ai sans cesse des prbs de méthodes/variables statiques-non statiques
 
Je vous propose la structure de code suivant pour la page externe.

 
Et le problème c'est que cela ne marche pas...
Etant donné que je ne peux pas invoquer pageExterne.service();
et que je ne sais pas faire de isValide() qui demanderait l'éxécution de service, et que je ne peux pas me passer de service car c'est lui qui me permet d'utiliser les servlets (session, cookies....)
 
 
Donc, pr clore ce long problème (je préfère le détailer, cela vous permet de comprendre mieux mon problème ) :
 
* Est-ce que ma méthode est bonne ?
* Dans ce cas, que pouvez vous me proposer pour la page externe ??
 
Infiniment merci !
Victor, pauvre stagiaire, avec le couteau sous la gorge  

Bien j'ai lu un petit peu ton post, mais je crois que t'es en train de refaire ce que tomcat fait déjà, c'est à dire gérer les sessions. Tomcat gere tout seul les sessions (soit par cookies, soit par passage d'un parametre dans l'url) ce qui revient un peu à ce que tu fais. Pour chaque client qui se connecte, tomcat genere un id que tu peux sauvergarder du coté du serveur. S'il n'est pas enregistré sur le serveur, c'est que c'est un nouveau client qui demande à s'indentifier, sinon c'est qu'il l'est déjà. Ce qui reviens à ce que tu disais :

 
Pour mieux comprendre mes propos tu peux lire ce post :
http://forum.hardware.fr/forum2.ph [...] subcat=390
 

Bien en fait, je m'y prends p-e mal, mais je ne cherche pas à refaire le boulot de tomcat !! Je cherche à m'en servir.
 
Pour moi l'idée de base est dc la suivante : on attribue un id session au client, et à chaque nouvelle page, le serveur compare l'id client dont il dipose et ce que fourni le client (par cookie ou passage de paramètre).
 
J'ai lu le lien que tu proposes, mais c'est un peu trop compliqué pour moi ! Et j'aimerais bien faire "simple"... j'ai l'impression de toucher le problème du doigt !
 
Plutot que de longues phrases, c'est le code qui vous expliquera le mieux ce que je veux faire.
 
Depuis la page que l'on veut consulter : les 3 lignes qui récupérent le travail du "gros code".
 
Pour simplifier : je n'arrive pas à appeller cette fonction/méthode/classe/page (depuis la page désirée) et faire en sorte qu'elle me retourne le résultat..
 
 
Help !

Si tu veux pas refaire le boulot de tomcat, sert toi uniquement de session et pas de cookies
 
En gros ca pourrait ressembler :
-Tu récupere l'id session du client dans la servlet : req.getSession().getId ()
-Tu vérifie qu'il est pas déjà stocké sur le serveur (dans un arrayList, une map, un vecteur ce que tu veux)
- S'il y est pas, tu vas sur ta page d'identification ou une fois le client identifié, t'ajoutera l'id session du client sur le serveur
- S'il y est le client est dejà identifié
 
Si tu veux faire d'autre vérification, tu peux ajouter des objets dans la session du client. Je rappelle que une session est attribuée à un client donné pour une durée limitée (qui peut etre configurée dans le web.xml je crois).
Passer par un cookie c'est un peu refaire une session en supposant en plus que le client accepte les cookies...
 
PS: petite question au passage, si on stocke les id sessions sur le serveur, comment sait on quand on peut les retirer ?

 
 
Bah c parfait ton idée... mais là où je bloque sacrément, c que pr moi (je me suis permis de numéroter tes points) en faisant 1 j'obtenais 2 !!!!
Donc il faudrait que tu me précises comment faire 2 !!!
 
halte stop !!!!    
Je viens de relire et je viens de voir une différence que je pige pas :
c'est quoi la différence entre  

et

??
Betement, je dirai qu'il y en a un qui intialise et un qui récupère... Mais le prb c que je fonctionnais avec la première solution HttpSession session = req.getSession(), mais que lorsque la session n'était pas expirée j'avais bien le meme id session !!!      
 
Et sinon, pr decider du tps max d'inactivité, je fais

 
 
Merci de ton aide....

En fait c'est simple, quand il se log tu fais un request.getSession().
Ensuite sur chaque page tu fais un truc du genre

Là tu te casses la tête pour rien jcrois
Donc plutôt que de faire un else, tu rediriges sur l'accueil dans le if.
Si l'utilisateur est bon, le reste de ta page s'éxécutera.

(ou alors j'ai pas tout lu et j'aurai du )

Dans mon cas :
en 1, tu obtiens l'id session du client, mais tu sais pas s'il est connecté ou pas, il faut donc le vérifier...
en 2, tu as à disposition une liste (par exemple un arrayList) d'id session qui sont connecté. Tu verifie donc que l'id session en 1 est contenu dans cette liste (contain () ou un truc comme ca pour savoir). S'il est dedans, c'est que le client est déjà identifié.. Sinon faut l'identifier et ajouter son id dans la liste.
 
Voilà c'était ma solution, mais je regarderais à ta place celle de Glod2 qui semble faire encore plus simplement ce que tu veux...

Oula, c'est vachement compliqué pour pas grand chose tout ça...
 
D'abord, il faut faire attention avec le request.getSession(false) : certaines JSP peuvent créer automatiquement une session, même si l'utilisateur n'est pas authentifié.  
Pour résoudre le problème (et aussi parce qu'une session peut être utile aussi pour un utilisateur anonyme) : une session peut servir à stocker des objets qui seront conserver entre 2 requêtes (c'est d'ailleurs tout l'intêrets des session). Quand le mot de passe de l'utilisateur a été vérifié, il suffit d'ajouter un attribut quelconque. Ça donne par exemple (la valeur n'a pas d'importance) :  

 
Pour tester si l'utilisateur est authentifié :  

 
Deuxième chose, au lieu de copier-coller le même code dans toutes les pages, c'est mieux (et plus simple) d'utiliser un filtre.  
En gros, un filtre est un objet (qui implemente l'interface Filter) qui sera appelé avant les servlets/jsp. Il reçoit la requête et la réponse, et peut en faire absolument ce qu'il veut.
 
Dans ton cas, le code de la méthode doFilter ressemblerait à ça :  

 
Le filtre doit être déclaré dans web.xml (ça se déclare comme une servlet, mais en utilisant <filter>, <filter-name>, <filter-class> et <filter-mapping> au lieu de respectivement <servlet>, <servlet-name>, <servlet-class> et <servlet-mapping> )
 
Autre solution : laisser le serveur géré tout ça lui-même, en utilisant <login-config> et <security-constraint> in web.xml (mais c'est un peu le bordel à mettre en place)

 
Bien, oui, ce que propose Glod2 est plus simple, en revanche, ca ne marche pas tellement (il est fort possible que ce soit moi qui n'arrive pas à l'implanter...   ) puisque quelque soit le delai d'inactivité, la session reste toujours valide..  

Bon, apres avoir répondu à patachou, je m'attaque la proposition de Bufff ...
 
1/
Ca me plait beaucoup dans le concept, en revanche, j'ai tjs raisonné avec un id (getId()), et là je me demande où part cette notion, qui pour moi était incontournable....   Je ne remets pas en cause , ce serait juste pour mieux comprendre... car je suis zéztomaqué   !
 
 
2/
Egalement, si quelqu'un pouvait développer l'idée que présentait patachou :

C'est très flou en effet pour moi...
 
3/
Web.xml, je connais pas trop... J'ai lu un jour qu'il suffisait de le copier/coller tel quel là où on voulait, et hop... Et comme ca marche, bien, je ne me suis pas posé de question...  
 
 
 
Merci..

1/
La session est un objet gardé sur le serveur, associé à un client particulier (en utilisant en général un cookie, mais ça, c'est au serveur de géré, pas au développeur d'application). On peut y stocker ce que l'on veut dedans (méthodes setAttribute et getAttribute).  
Ma proposition, c'est de mettre un attribut dans la session au moment où tu vérifies l'utilisateur. Cet attribut restera là pour les requêtes suivantes, ce qui permet de vérifier l'utilisateur simplement en regardant si l'attribut de session est présent.
2/
ça me semble très compliqué pour rien. Sauf cas très particuliers, en tant que dévelopeur d'application, tu n'as pas à t'occuper des IDs de session, c'est le boulot du serveur.
3/
web.xml, c'est le descripteur d'application. En (très) résumé, c'est le fichier de configuration principal de ton application web. Dedans, on y trouve (entre autres) : declaration des servlets et des filtres, declaration des pages d'erreur, réferences à d'autres objets J2EE (EJB, par exemple), déclarations d'éléments de sécurité, configuration des sessions (timeout, par exemple)
Effectivement, un web.xml tout près peu très bien fonctionner si tu n'utilises que des JSP, mais c'est indispensable de travailler dessus dès que tu fais des trucs un peu plus compliqués (utilisation de servlets ou de filtres, par exemple)
 
Voilà, j'espère que j'ai été clair

1/
Tout compris   Victor très fort ( )
2/
C'est marrant, dire que je me basais la dessus....  
3/
Bien en fait, j'ai aucune page en JSP, je n'ai que des servlets.....C'est un peu en contradiction avec ce que tu dis      
 
Bonus/
Bon, j'ai testé ce que tu m'as dis... Ca marche très bien Victor content    
En revanche, j'ai pas utilisé "tes" filtres... parce que je trouvais cela plus compliqué que d'utiliser les betes lignes suivantes (bah ouais, je trouve ca moins long en plus !   )  

Tes filtres sont-ils nécessaires ?? (sécurité, "propreté" ).....
 
 
Mârci beaucoup en tout cas pr cette solution simple pr un grand débutant java/servlet comme moi  

Et au passage, peux tu m'expliquer ce que je trouve etre une super bizarrerie....
Quand je mets ce que tu proposes ca va tres bien:

 
mais, qd je veux mettre (je suis curieux.... )

(true en minuscule)
 
ou bien meme

(true tout court)
 
--> Le compilateur râle..... Je suis aller voir la doc java et il parrait qu'il faut mettre en objet en deuxième paramètre... Mais je fais pas lien (je ne sais pas vraiement ce qu'est un Objet... pour moi c'est un objet "bete"... enfin, c'est pas tres clair, mais je ne vois pas la différence entre un Object et un objet...   )

Boolean.true n'existe pas (tu dois obtenir une erreur de syntax), parce que true est un mot réservé de Java, et ne peut donc pas être utilisé comme nom pour une variable.  
true est une valeur de type boolean, qui est un type primitif et pas un objet. On ne peut mettre que des objets dans la session.
 
Pour l'histoire des filtres : non, ce n'est pas nécessaire, mais c'est plus propre (ça évite de dupliquer du code).  
Et une fois que tu as compris comment marchent les filtres, c'est vraiment super utile pour plein de choses (par exemple, si toutes tes pages utilisent une connexion à une base de donnée, tu peux mettre l'ouverture et la fermeture de la connexion dans un filtre)

Et boolean.TRUE est un objet alors ?? C'est quoi cette conversion tordue ???
 
A ce propos, si je veux stocker le nom du user dans un attribut de session, et que je fais

Et bien le compilateur me dit :  incompatible types
Donc j'imagine qu'il faut faire une conversion, mais j'ai l'impression qu'il y a 36000 facon de faire !!
(String).id_user
Parse_je_sais_plus_quoi(id_user)
id_user.toString()
etc....
 
 
 

 
Je ne vois pas où il y aurait duplication... Mes qqs lignes, je les place au début de chaque page, mais ton filtre aussi   ?? Non ?
 
 

j'ai pas mal de connexion à une base, mais ce n'est pas systématique..
Je procède comme ca :

1/ C'est bien ? (je demande...on ne sait jamais)
2/ Et donc, je suppose que c'est cela que tu placerais dans le filtre...
Mais le reste de ma page, je le mets où ???  
Cette question doit d'ailleurs rejoindre ce que tu me réponderas pour l'histoire de duplication de code..
 
 

Oui, un objet de la classe Boolean. Pour toutes ces question de types primitifs vs objets, ou conversion de type, je te conseille de regarder dans à peu près n'importe quel tutorial Java, c'est en général bien expliqué.  
Sinon, réponse courte : pour récupérer une String de la session, c'est :

 
Tu dois placer quelques lignes au début de chaque page, et tu vois pas où il y a duplication de code?
 
Pour le filtre, non, il n'y a rien à ajouter aux pages.  
Pour bien comprendre comment ça marche, il faut savoir comment le serveur traite une requête. Pour chaque requête, il va construire une liste de filtres (éventuellement vide), et mettre la servlet au bout (cette liste, c'est le troisième paramètre de la méthode doFilter, le FilterChain).  
Le premier filtre va être appelé, et, dans sa méthode doFilter, il y aura en général une instruction "chain.doFilter(request, response);", qui va appeler l'élément suivant de la liste (filtre suivant ou servlet si on est arrivé au bout).
Avec un seul filtre, on aura donc quelque chose du genre

• le client fait une requête
• doFilter du filtre est appelée
• le filtre fait ce qu'il a faire
• le filtre appelle chain.doFilter
• la méthode doGet (ou doPost, ...) de la servlet est appelée
• après l'exécution de la servlet, on revient dans le filtre, qui peut encore faire ce qu'il veut (du nettoyage, par exemple)

Donc le filtre s'exécute "autour" de la serlvet. C'est pour ça que c'est particulièrement utile pour éviter de dupliquer du code qui aurait du être au début de chaque page.  
Autre avantage : le filtre est mappé sur un motif d'url (comme les servlets), donc si tu mets ton filtre sur "/protected/*", tout ce qui est dans "protected" sera automatiquement protégé (pas de risque d'oublier une page, et ça marche aussi sur les pages statiques).
 
Maintenant, pour communiquer entre le filtre et la servlet, il suffit de placer des attributs dans la requête (HttpServletRequest.get/setAttribute)

1/ Ça illustre très bien mon propos sur l'utilité des filtres... Suppose que tu copies-colles ce code dans toutes les pages qui ont besoin d'utiliser la base de données. Tu fais quoi si un jour, l'url de connexion change? Il faut modifier toutes tes pages...  
2/ j'espère que mon explication du dessus répond à ta question

MegaTop.... j'ai tout compris....
 
Donc, ca y'est, je me lance dans ton filter...
En revanche, ca coince quand je lance tomcat....
 
1/ Voici mon fichier web.xml

 
Je t'invite à faire du tri... car comme je le disais j'ai copié/collé ce web.xml depuis le debut, sans trop savoir comment il fonctionnait..
 
2/Voici ma classe de filtre que j'ai appellé Authentification  

 
3/Et voici ce que me dit Tomcat au lancement

 
 
Astuce : mon rep c'est vlm7....mais ca doit pas etre une grosse surprise  
 
 
Merci de ton aide !

Ton filtre, il doit implémenter javax.servlet.Filter, et pas étendre HttpServlet (il te faudra aussi implémenter init et destroy).
 
Sinon, il y a un problème avec ton web.xml : si tu mets le filtre sur /*, comment est-ce que tu fais pour afficher la page de login? Je te conseille de plutôt mapper le filtre sur un sous-répertoire (et au passage, vire la servlet "invoker", et mappe directement tes servlets à toi)

 
Comme je le disais, j'ai jamais vraiment parmétrer un fichier web.xml, et j'esssaie plein de trucs (avec ou sans les / avec ou sans /servlet...)
bref, je suis perdu...
 
J'ai donc fais cela :

Et ca ne marche absolument pas...
L'arboresence est la suivate :
webapps/vlm7/protected pour les trucs qui doivent etres protégés
webapps/vlm7/ pour le reste  
 
Donc, c'est quoi qui ne vas pas dans mon web.xml ??
Merci  

Essaie déjà de mettre : /protected/* dans <url-pattern>
Sinon, tu dis que ça marche pas, mais c'est quoi qui ne marche pas?

Après modification faite, tomcat me dit :
 

 
 
Et attend : la meilleur pr la fin : j'ai donc enlevé complétement la partie filtre, et ca ne démarre tjs pas !!!
Donc, avec l'aborscence que j'ai donné, comment faut-il parametrer le début ???? Ca doit etre tout con, mais je m'y perds avec les /servelt les vlm7/servlet ou les servlet/vlm7....
Parce que les tuto sont bien gentils, mais comme ils ne donnent pas l'arbo, je n'arrive pas à "calquer" chez moi...
 
merci !

Ça, c'est le DOCTYPE pour la norme servlet 2.2. Les filtres sont apparus en 2.3. Essaie de mettre ça à la place (j'imagine que tu utilises un Tomcat >= 4.0, donc

 
Ensuite, l'ordre des éléments peut avoir de l'importance. L'ordre est : filter, filter-mapping, servlet, servlet-mapping, session-config, welcome-file-list

J'ai corrigé mais rien n'y fait....
 
Je commence à déprmier sévèrement    
En enlevant tout ce qui parle de filtre, je n'arrive pas à configurer mon web.xml
 
Avant j'utilisais ca :

 
Mais il parait que "c'est pas bien"....
Donc je voulais revenir à un truc propre "home made"...
 
Mais c'est la catastrophe.... Ca doit pourtant pas etre dur, mais j'ai l'impression d'avoir essayé toutes les possiblités, en vain !!  
 
 
Gadgets:
Mon arbo :

 
Les classes qui ne doivent pas etre protégées :

 
Les classes qui doivent etres protégées (y'a pas tout...):

New !!!
Bon, en galérant depuis ce matin, j'ai reussi à faire marcher convenablement les classes non protégées...
 
En revanche, je n'arrive pas à acceder aux classes protégées !!
 
En effet, avec :

 
J'obtiens :

 
 
 
Voilà.... et je ne vois pas comment paramétrer mon <servlet-class> pour que ca marche....
 
merci !

ben ton package il s'appelle protected pas protect...
 

 
Arff    
y'a effectivement un prb, mais pas celui que tu crois : sur mon screen shoot ca s'appelle bien "protected", et ds le code que j'ai collé "protect", mais à ce moment là, le rép s'appellait bien "protect"...
 
ET CA NE MARCHE PAS....
 
Donc pour repartir sur de bonnes bases :
*le dossier s'appelle protected
*dans le web.xml aussi (je vais de ce pas éditer mon message précédent)
 
 
Autres indices pour m'aider :
1/je ne sais pas ce qu'est un package
 
2/je ne sais pas du tout si dans le web.xml ca change qqchose de faire
2a/

2b/

2c/

 
3/Dans ma classe LectureTable, je n'ai pas mis de truc genre

(juste avant les imports), comme je le vois parfois à force de chercher à droite à gauche...

Le nom du package doit être le même que l'arborescence ou se trouve la classe.
Dans ton cas :
package protected;
pour les classes qui sont dans le répertoire protected.

 
J'ai donc rajouté package protected; en haut de ma classe LectureTable...
Mais ca ne marche tjs pas    

 
Et ceci avec les déclarations suivantes :

 
Et en tappant:

 
 
remarque : j'ai tout mis protect et non protected parce que protected est un mot réservé...

Et tu as aussi renommé ton dossier en protect ?

Oui bien sur !!!    

Bonjour bonjour....
 
Je me permets un petit up, parce que j'avais baissé les bras, mais j'ai vraiment besoin de faire marcher cette histoire...    
 
Pr ceux qui ont le courage de lire : c'est parfait, vous aller comprendre mon problème parfaitement.
 
Sinon, je fais un premier résumé de mon problème :
je n'arrive pas à acceder à des servlets dans un sous répetoire !

Ex : webapps\monapp\WEB-INF\classes\Toto.class
-> j'arrive tres bein à y acceder en configurant le xml de la manière suivante :  

et en demandant : http://localhost:8080/monapp/Toto
 
et revanche, ex2 : webapps\monapp\WEB-INF\classes\protect\Titi.class
et en déclarant  
 

 
et en demandant http://localhost:8080/monapp/Titi  
--> ca ne marche pas !!!
(et j'ai mis en haut de ma class Titi :

tout en sachant pas tellement si c'est utile, et si oui, à quoi ca sert   )
 
Merci de votre aide  

Ben écoute, pour une servlet dont le package est :

L'entrée suivante du web.xml

 
et où les classes sont dans :

fonctionne, t'as vraiment dû oublier un truc...