IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Servlets/JSP Java Discussion :

Attributs SESSION ou parametres REQUEST?


Sujet :

Servlets/JSP Java

  1. #1
    Membre éclairé
    Inscrit en
    Février 2008
    Messages
    457
    Détails du profil
    Informations forums :
    Inscription : Février 2008
    Messages : 457
    Par défaut Attributs SESSION ou parametres REQUEST?
    Bonjour à tous,

    Je me demandais qu'elle est le meilleur choix, au niveau des performances, lorsque je communique entre deux servlets..

    Soit je passe les paramètres grâce à l'objet Request(à l'aide d'un formulaire, ne supporte pas les objets type array,map,..)
    Soit grâce à l'objet de session et setAttributes .. (où l'on peut lui fournir tout type d'objet)


    Voilà, j'espère que vous pourrez m'éclairer un peu plus.

    Merci d'avance.

  2. #2
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 313
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 313
    Billets dans le blog
    1
    Par défaut
    Entre 2 servlets ?
    Servlet1 appelle Servlet2, c'est bien ça ?

    Alors, incontestablement c'est Request...

    Côté Servlet1
    en passant par request.setAttribute("nom", objet)

    Côté Servlet2
    en passant par Object objet = request.getAttribute("nom")
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  3. #3
    Membre éclairé
    Inscrit en
    Février 2008
    Messages
    457
    Détails du profil
    Informations forums :
    Inscription : Février 2008
    Messages : 457
    Par défaut
    Pas exactement.

    En fait, Servlet1 génère une page HTML (avec formulaire), donc j'ai la possibilité d'utiliser l'objet session.
    Ce formulaire envoie ensuite vers la Servlet2.

    Je n'ai donc pas la possibilité d'utiliser request.getAttributes , seulement getParameters il me semble..

  4. #4
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 313
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 313
    Billets dans le blog
    1
    Par défaut
    Dans ce cas de figure, il y a 2 possibilités :

    1- tu n'as pas tous les champs voulus dans le formulaire => il faut passer par session
    2- tu as tous les champs, tu peux utiliser request

    Sachant qu'en 1, tu peux passer par des champs "hidden" pour palier au problème.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Membre éclairé
    Inscrit en
    Février 2008
    Messages
    457
    Détails du profil
    Informations forums :
    Inscription : Février 2008
    Messages : 457
    Par défaut
    Citation Envoyé par OButterlin Voir le message
    Dans ce cas de figure, il y a 2 possibilités :

    1- tu n'as pas tous les champs voulus dans le formulaire => il faut passer par session
    2- tu as tous les champs, tu peux utiliser request

    Sachant qu'en 1, tu peux passer par des champs "hidden" pour palier au problème.
    Voilà, c'est exactement ce que je fais..
    Afin d'avoir un genre de tableau, je passe par des select multiple "hidden" quej e récupère avec request alors que j'aurais probablement pu le faire avec session.

    Ce que j'aimerais savoir, c'est est-ce que l'un est préférable à l'autre au vue des performances? (ou de la sécurité?)

  6. #6
    Membre chevronné
    Avatar de link256
    Profil pro
    Développeur Java
    Inscrit en
    Février 2003
    Messages
    596
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Février 2003
    Messages : 596
    Par défaut
    Pour ce qui est du coté performance si tu penses à la mémoire utiliser par le stockage en session du moment que la servlet2 supprime les objets juste après les avoir récupérés.

    Coté sécurité il me semble que via la session il n'ya pas trop de problème de sécurité mais sa reste que mon avis, je ne me suis jamais trop penché sur la question.

    Si tu passes par la request tu as juste à crypter et décrypter les données transmise.

  7. #7
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 313
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 313
    Billets dans le blog
    1
    Par défaut
    D'un point de vue sécurité, la session sera mieux. L'inconvénient des champs hidden c'est qu'ils sont visibles en clair dans la page (si tu édites le code source).
    Avec la session, tu ne les as pas transmis et donc ils restent invisibles (en théorie, un bon hacker pourras peut-être trouver une faille sur ton site)...
    Ensuite, il y a la problématique de la mémoire utilisée (inutilement) par la session... ça peut devenir un problème aussi...
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  8. #8
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 313
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 313
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par link256 Voir le message
    Si tu passes par la request tu as juste à crypter et décrypter les données transmise.
    Histoire de ne pas être le seul à avoir été corrigé par des spécialistes de la DGA, on parle de chiffrer / déchiffrer, pas crypter / décrypter (qui relève du hacking)
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  9. #9
    Membre éclairé
    Inscrit en
    Février 2008
    Messages
    457
    Détails du profil
    Informations forums :
    Inscription : Février 2008
    Messages : 457
    Par défaut
    Ok merci à vous pour ces informations !

  10. #10
    Membre chevronné
    Avatar de link256
    Profil pro
    Développeur Java
    Inscrit en
    Février 2003
    Messages
    596
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : Février 2003
    Messages : 596
    Par défaut
    Citation Envoyé par OButterlin Voir le message
    Histoire de ne pas être le seul à avoir été corrigé par des spécialistes de la DGA, on parle de chiffrer / déchiffrer, pas crypter / décrypter (qui relève du hacking)
    Merci pour l'info OButterlin

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Session en parametre par défaut d'une fonction
    Par Madfrix dans le forum Langage
    Réponses: 2
    Dernier message: 14/02/2010, 15h13
  2. Ouverture de session avec parametre
    Par toine62 dans le forum Langage
    Réponses: 4
    Dernier message: 03/12/2008, 16h32
  3. Utilisation de session et de request
    Par doukou10 dans le forum Servlets/JSP
    Réponses: 3
    Dernier message: 27/09/2008, 18h33
  4. [Debutant]scop=session et scop=request
    Par aarifinfo dans le forum Struts 1
    Réponses: 1
    Dernier message: 23/04/2007, 10h23
  5. [JSP / SERVLET] Attribut Session
    Par JWillow dans le forum Servlets/JSP
    Réponses: 1
    Dernier message: 22/02/2005, 18h34

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo