On me dit qu'il faut éviter d'utiliser les variables Session car des pirates
qui tenteraient de venir sur le site, pourraient avoir accès au données
contenues. Cela est-il vrai ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pierre Goiffon
Dans le message:%, Michel Thiffault a écrit:
Par contre, les variables sessions consument des ressources inutilement sur le serveur
Il ne faut quand même pas exagérer : les sessions consomment très peu, c'est sur le volume que des prb se poseront. Si l'on en est dans ces considérations, on envisagera des méthodes assez radicales - je ne crois pas que ce soit le cas de Olivier qui posait la question.
Les sessions ont l'avantage de ne consommer qu'un seul cookie pour n variables et un tracking de l'utilisateur, et même avec certains systèmes on peut fonctionner avec un identifiant en URL à la place du cookie. Remplacer 30 variables par 30 cookies pour une raison de consommation de ressources serveur me parait donc difficile à justifier.
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Dans le message:%23xByN20WDHA.2236@TK2MSFTNGP10.phx.gbl,
Michel Thiffault <mtifo@h.ot_m.ai_l.com> a écrit:
Par contre, les variables sessions consument des
ressources inutilement sur le serveur
Il ne faut quand même pas exagérer : les sessions consomment très peu,
c'est sur le volume que des prb se poseront. Si l'on en est dans ces
considérations, on envisagera des méthodes assez radicales - je ne crois
pas que ce soit le cas de Olivier qui posait la question.
Les sessions ont l'avantage de ne consommer qu'un seul cookie pour n
variables et un tracking de l'utilisateur, et même avec certains
systèmes on peut fonctionner avec un identifiant en URL à la place du
cookie. Remplacer 30 variables par 30 cookies pour une raison de
consommation de ressources serveur me parait donc difficile à justifier.
--
_________________________________________________________
/
. Pierre GOIFFON .
. p g o i f f o n @ w e b c i t y . f r .
_________________________________________________________/
Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php
Par contre, les variables sessions consument des ressources inutilement sur le serveur
Il ne faut quand même pas exagérer : les sessions consomment très peu, c'est sur le volume que des prb se poseront. Si l'on en est dans ces considérations, on envisagera des méthodes assez radicales - je ne crois pas que ce soit le cas de Olivier qui posait la question.
Les sessions ont l'avantage de ne consommer qu'un seul cookie pour n variables et un tracking de l'utilisateur, et même avec certains systèmes on peut fonctionner avec un identifiant en URL à la place du cookie. Remplacer 30 variables par 30 cookies pour une raison de consommation de ressources serveur me parait donc difficile à justifier.
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Michel Thiffault
je n'apportais que des précisions (tu pourras deviner dans ce qui suit que je n'ai aucune estime pour les variables session). Mais il y a d'autres avantages à utiliser les cookies au lieu de variables session (puisque tu sembles vouloir pousser la discussion, ce qui est bien, c'est un sujet intéressant):
- Les variables sessions meurent si on sauvegarde/modifie GLOBAL.ASA (pas avec les cookies). - Les variables sessions meurent si l'application est redémarée (pas avec les cookies). - La durée de vie d'un cookies est contrôlable (on peut aussi avec les sessions, mais avec de grands coûts en ressources: j'imagine mal mettre l'expiration des sessions à huit heures). - Les variables sessions ne fonctionnent pas dans un "web farm" (puisqu'elles sont stockées sur le serveur lui-même). Pour avoir des variables sessions en "web farm" un "state server" est nécessaire. - Dans le cas de popup, une deuxième session peu être créée dans IIS si Internet Explorer roule dans un process séparé (L'OS décide maintenant si les fenêtres d'Explorer roulent dans un process séparé ou non, l'option a disparu avec IE5.5 je crois). - Les sessions restent "vivantes" plusieurs minutes après le départ du visiteur, augmentant énormément le coût en ressources sur le serveur inutilement. C'est spécialement pénalisant sur les sites avec beaucoup de visiteurs ou les serveurs hébergeant plusieurs sites. - Récupérer la valeur d'une variable session ne se fait que du côté serveur, un cookie est lisible sur le serveur en ASP ou sur le client avec du "client-side scripting".
Il y en a d'autre... mais je dois y aller maintenant. C'est mon opinion: éviter les variables sessions comme la peste!
Bonne journée
"Pierre Goiffon" wrote in message news:bgoch6$gms$
Dans le message:%, Michel Thiffault a écrit: > Par contre, les variables sessions consument des > ressources inutilement sur le serveur
Il ne faut quand même pas exagérer : les sessions consomment très peu, c'est sur le volume que des prb se poseront. Si l'on en est dans ces considérations, on envisagera des méthodes assez radicales - je ne crois pas que ce soit le cas de Olivier qui posait la question.
Les sessions ont l'avantage de ne consommer qu'un seul cookie pour n variables et un tracking de l'utilisateur, et même avec certains systèmes on peut fonctionner avec un identifiant en URL à la place du cookie. Remplacer 30 variables par 30 cookies pour une raison de consommation de ressources serveur me parait donc difficile à justifier.
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
je n'apportais que des précisions (tu pourras deviner dans ce qui suit que
je n'ai aucune estime pour les variables session). Mais il y a d'autres
avantages à utiliser les cookies au lieu de variables session (puisque tu
sembles vouloir pousser la discussion, ce qui est bien, c'est un sujet
intéressant):
- Les variables sessions meurent si on sauvegarde/modifie GLOBAL.ASA (pas
avec les cookies).
- Les variables sessions meurent si l'application est redémarée (pas avec
les cookies).
- La durée de vie d'un cookies est contrôlable (on peut aussi avec les
sessions, mais avec de grands coûts en ressources: j'imagine mal mettre
l'expiration des sessions à huit heures).
- Les variables sessions ne fonctionnent pas dans un "web farm"
(puisqu'elles sont stockées sur le serveur lui-même). Pour avoir des
variables sessions en "web farm" un "state server" est nécessaire.
- Dans le cas de popup, une deuxième session peu être créée dans IIS si
Internet Explorer roule dans un process séparé (L'OS décide maintenant si
les fenêtres d'Explorer roulent dans un process séparé ou non, l'option a
disparu avec IE5.5 je crois).
- Les sessions restent "vivantes" plusieurs minutes après le départ du
visiteur, augmentant énormément le coût en ressources sur le serveur
inutilement. C'est spécialement pénalisant sur les sites avec beaucoup de
visiteurs ou les serveurs hébergeant plusieurs sites.
- Récupérer la valeur d'une variable session ne se fait que du côté serveur,
un cookie est lisible sur le serveur en ASP ou sur le client avec du
"client-side scripting".
Il y en a d'autre... mais je dois y aller maintenant. C'est mon opinion:
éviter les variables sessions comme la peste!
Bonne journée
"Pierre Goiffon" <piR@nowhere.invalid> wrote in message
news:bgoch6$gms$1@reader1.imaginet.fr...
Dans le message:%23xByN20WDHA.2236@TK2MSFTNGP10.phx.gbl,
Michel Thiffault <mtifo@h.ot_m.ai_l.com> a écrit:
> Par contre, les variables sessions consument des
> ressources inutilement sur le serveur
Il ne faut quand même pas exagérer : les sessions consomment très peu,
c'est sur le volume que des prb se poseront. Si l'on en est dans ces
considérations, on envisagera des méthodes assez radicales - je ne crois
pas que ce soit le cas de Olivier qui posait la question.
Les sessions ont l'avantage de ne consommer qu'un seul cookie pour n
variables et un tracking de l'utilisateur, et même avec certains
systèmes on peut fonctionner avec un identifiant en URL à la place du
cookie. Remplacer 30 variables par 30 cookies pour une raison de
consommation de ressources serveur me parait donc difficile à justifier.
--
_________________________________________________________
/
. Pierre GOIFFON .
. p g o i f f o n @ w e b c i t y . f r .
_________________________________________________________/
Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php
je n'apportais que des précisions (tu pourras deviner dans ce qui suit que je n'ai aucune estime pour les variables session). Mais il y a d'autres avantages à utiliser les cookies au lieu de variables session (puisque tu sembles vouloir pousser la discussion, ce qui est bien, c'est un sujet intéressant):
- Les variables sessions meurent si on sauvegarde/modifie GLOBAL.ASA (pas avec les cookies). - Les variables sessions meurent si l'application est redémarée (pas avec les cookies). - La durée de vie d'un cookies est contrôlable (on peut aussi avec les sessions, mais avec de grands coûts en ressources: j'imagine mal mettre l'expiration des sessions à huit heures). - Les variables sessions ne fonctionnent pas dans un "web farm" (puisqu'elles sont stockées sur le serveur lui-même). Pour avoir des variables sessions en "web farm" un "state server" est nécessaire. - Dans le cas de popup, une deuxième session peu être créée dans IIS si Internet Explorer roule dans un process séparé (L'OS décide maintenant si les fenêtres d'Explorer roulent dans un process séparé ou non, l'option a disparu avec IE5.5 je crois). - Les sessions restent "vivantes" plusieurs minutes après le départ du visiteur, augmentant énormément le coût en ressources sur le serveur inutilement. C'est spécialement pénalisant sur les sites avec beaucoup de visiteurs ou les serveurs hébergeant plusieurs sites. - Récupérer la valeur d'une variable session ne se fait que du côté serveur, un cookie est lisible sur le serveur en ASP ou sur le client avec du "client-side scripting".
Il y en a d'autre... mais je dois y aller maintenant. C'est mon opinion: éviter les variables sessions comme la peste!
Bonne journée
"Pierre Goiffon" wrote in message news:bgoch6$gms$
Dans le message:%, Michel Thiffault a écrit: > Par contre, les variables sessions consument des > ressources inutilement sur le serveur
Il ne faut quand même pas exagérer : les sessions consomment très peu, c'est sur le volume que des prb se poseront. Si l'on en est dans ces considérations, on envisagera des méthodes assez radicales - je ne crois pas que ce soit le cas de Olivier qui posait la question.
Les sessions ont l'avantage de ne consommer qu'un seul cookie pour n variables et un tracking de l'utilisateur, et même avec certains systèmes on peut fonctionner avec un identifiant en URL à la place du cookie. Remplacer 30 variables par 30 cookies pour une raison de consommation de ressources serveur me parait donc difficile à justifier.
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Michel Thiffault
Je tiens à souligner que ceci n'est pas une guerre, simplement une discussion technique (j'aime bien préciser car il est difficile de communiquer les émotions par écrit et certains confondent "technique" et "religion": Intel/AMD, Windows/Linux, etc.).
En quoi comparer cookies et variables session est-il dépourvu de sens? Les deux ont la même utilité à la base (permettre de contourner les problèmes liés aux propriétés "stateless" de HTTP).
"Pierre Goiffon" wrote in message news:bgqufm$14g$
Dans le message:, Michel Thiffault a écrit: > Il y en a d'autre... mais je dois y aller maintenant. C'est mon > opinion: éviter les variables sessions comme la peste!
Encore une fois, on ne choisit pas les technologies parce qu'on les aime ou pas, ou essaie de répondre au mieux au besoin exprimé. Ainsi confronter sessions et cookies me parait assez dépourvu de sens - mais en tout cas, cela aura permi de noter quelques pour et contre :)
Excellente continuation
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Je tiens à souligner que ceci n'est pas une guerre, simplement une
discussion technique (j'aime bien préciser car il est difficile de
communiquer les émotions par écrit et certains confondent "technique" et
"religion": Intel/AMD, Windows/Linux, etc.).
En quoi comparer cookies et variables session est-il dépourvu de sens? Les
deux ont la même utilité à la base (permettre de contourner les problèmes
liés aux propriétés "stateless" de HTTP).
"Pierre Goiffon" <piR@nowhere.invalid> wrote in message
news:bgqufm$14g$1@reader1.imaginet.fr...
Dans le message:esyETA2WDHA.3404@tk2msftngp13.phx.gbl,
Michel Thiffault <mtifo@h.ot_m.ai_l.com> a écrit:
> Il y en a d'autre... mais je dois y aller maintenant. C'est mon
> opinion: éviter les variables sessions comme la peste!
Encore une fois, on ne choisit pas les technologies parce qu'on les aime
ou pas, ou essaie de répondre au mieux au besoin exprimé. Ainsi
confronter sessions et cookies me parait assez dépourvu de sens - mais
en tout cas, cela aura permi de noter quelques pour et contre :)
Excellente continuation
--
_________________________________________________________
/
. Pierre GOIFFON .
. p g o i f f o n @ w e b c i t y . f r .
_________________________________________________________/
Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php
Je tiens à souligner que ceci n'est pas une guerre, simplement une discussion technique (j'aime bien préciser car il est difficile de communiquer les émotions par écrit et certains confondent "technique" et "religion": Intel/AMD, Windows/Linux, etc.).
En quoi comparer cookies et variables session est-il dépourvu de sens? Les deux ont la même utilité à la base (permettre de contourner les problèmes liés aux propriétés "stateless" de HTTP).
"Pierre Goiffon" wrote in message news:bgqufm$14g$
Dans le message:, Michel Thiffault a écrit: > Il y en a d'autre... mais je dois y aller maintenant. C'est mon > opinion: éviter les variables sessions comme la peste!
Encore une fois, on ne choisit pas les technologies parce qu'on les aime ou pas, ou essaie de répondre au mieux au besoin exprimé. Ainsi confronter sessions et cookies me parait assez dépourvu de sens - mais en tout cas, cela aura permi de noter quelques pour et contre :)
Excellente continuation
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Pierre Goiffon
Dans le message:%, Michel Thiffault a écrit:
En quoi comparer cookies et variables session est-il dépourvu de sens? Les deux ont la même utilité à la base (permettre de contourner les problèmes liés aux propriétés "stateless" de HTTP).
Suivant le besoin, on employera les cookies ou les sessions. Les 2 peuvent être très utiles suivant le cadre d'utilisation.
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
Dans le message:%23oswtiCXDHA.1680@tk2msftngp13.phx.gbl,
Michel Thiffault <mtifo@h.ot_m.ai_l.com> a écrit:
En quoi comparer cookies et variables session est-il dépourvu de
sens? Les deux ont la même utilité à la base (permettre de contourner
les problèmes liés aux propriétés "stateless" de HTTP).
Suivant le besoin, on employera les cookies ou les sessions. Les 2
peuvent être très utiles suivant le cadre d'utilisation.
--
_________________________________________________________
/
. Pierre GOIFFON .
. p g o i f f o n @ w e b c i t y . f r .
_________________________________________________________/
Un grand merci à OE Quote Fix pour rendre OE utilisable :)
=> http://home.in.tum.de/~jain/software/quotefix.php
En quoi comparer cookies et variables session est-il dépourvu de sens? Les deux ont la même utilité à la base (permettre de contourner les problèmes liés aux propriétés "stateless" de HTTP).
Suivant le besoin, on employera les cookies ou les sessions. Les 2 peuvent être très utiles suivant le cadre d'utilisation.
-- _________________________________________________________ / . Pierre GOIFFON . . p g o i f f o n @ w e b c i t y . f r . _________________________________________________________/ Un grand merci à OE Quote Fix pour rendre OE utilisable :) => http://home.in.tum.de/~jain/software/quotefix.php
