avec Asp.Net 2.0 je'utilise le composant Login qui permet de garder le
"login/mot de passe" de la dernière connexion. Pour moi il y a donc création
d'u cookie sur le disque du PC connecté.
Mes utilisateurs intranautes me disent que de ci de là cette "dernière
connexion" est perdue et il doivent retaper leur login/mot de passe.
Savez-vous pq ? Y a-t-il une période d'expiration pour le cookie ?
Bon finalement je suis pas sûr d'avoir compris. Il y a apparemment une notion de timeout pour la session et pour l'authentification. Pour la session, cela veut dire qu'on doit se relogger après X minutes d'inactivité. Pour l'authentification, cela veut dire qu'on perd les infos d'authentification après X minutes. Jusque là, est-ce clair et surtout vrai ? Donc je suppose que le timeout ci-dessous concerne l'authentification...
Bon finalement je suis pas sûr d'avoir compris. Il y a apparemment une
notion de timeout pour la session et pour l'authentification.
Pour la session, cela veut dire qu'on doit se relogger après X minutes
d'inactivité.
Pour l'authentification, cela veut dire qu'on perd les infos
d'authentification après X minutes.
Jusque là, est-ce clair et surtout vrai ?
Donc je suppose que le timeout ci-dessous concerne l'authentification...
"Oriane" <oriane@noemail.noemail> a écrit dans le message de
news:372312DB-C55B-456B-95AB-AB0A78501425@microsoft.com...
Bon finalement je suis pas sûr d'avoir compris. Il y a apparemment une notion de timeout pour la session et pour l'authentification. Pour la session, cela veut dire qu'on doit se relogger après X minutes d'inactivité. Pour l'authentification, cela veut dire qu'on perd les infos d'authentification après X minutes. Jusque là, est-ce clair et surtout vrai ? Donc je suppose que le timeout ci-dessous concerne l'authentification...
Le paramètre que vous indiquez correspond effectivement au laps de temps au bout duquel un utilisateur doit se reconnecter (30 min par défaut en Asp .Net 2.0). C'est le délai d'expiration du ticket de sécurité. Attention avec le paramètre slidingExpiration (qui est vrai par défaut). Il demande à Asp .Net de ne mettre à jour le cookie que si >50% du temps (donc plus de 15min par défaut) s'est écoulé. Prenons l'exemple d'un utilisateur qui se connecte à 12h00. L'expiration d'origine est donc prévue pour 12h30. S'il se reconnecte à 12h14, l'expiration reste à 12h30... donc le délai entre l'inactivité et l'arret est de 15min. S'il se reconnecte à 12h16 alors l'expiration passe à 12h46. Donc le délai varie entre 50 et 100% du timeout.
Quoi qu'il en soit le ticket est enregistré dans un cookie. C'est d'ailleurs la raison d'être du sliding : evitez les alertes de sécurités pour les postes qui sont configuré pour lever une boite de dialogue sur l'arrivée de cookie.
De manière plus globale, pour une session, la persistence des infos fluctuent : par défaut, l'état de session est conservé dans un cookie suivant le délai défini dans <sessionState. timeout="40". cookieless="true|false". />. Vous remarquerez le flag cookieless : Pour les postes qui ne peuvent accepter les cookies, il s'agit de faire transiter l'état de session comme un ID dans l'url. Enfin pour les informations non sensibles d'un point de vue sécurité, vous pouvez utiliser des cookies permanents dans vos applications mais pour les logins, je ne saurai trop vous le déconseiller.
L'article suivant semble une bonne source d'information sur le sujet http://www.dotnetguru.org/articles/Sessions/Session.htm
HTH, C.
"Oriane" wrote in message news:
Bon finalement je suis pas sûr d'avoir compris. Il y a apparemment une notion de timeout pour la session et pour l'authentification. Pour la session, cela veut dire qu'on doit se relogger après X minutes d'inactivité. Pour l'authentification, cela veut dire qu'on perd les infos d'authentification après X minutes. Jusque là, est-ce clair et surtout vrai ? Donc je suppose que le timeout ci-dessous concerne l'authentification...
Le paramètre que vous indiquez correspond effectivement au laps de temps au
bout duquel un utilisateur doit se reconnecter (30 min par défaut en Asp
.Net 2.0). C'est le délai d'expiration du ticket de sécurité. Attention avec
le paramètre slidingExpiration (qui est vrai par défaut). Il demande à Asp
.Net de ne mettre à jour le cookie que si >50% du temps (donc plus de 15min
par défaut) s'est écoulé.
Prenons l'exemple d'un utilisateur qui se connecte à 12h00. L'expiration
d'origine est donc prévue pour 12h30. S'il se reconnecte à 12h14,
l'expiration reste à 12h30... donc le délai entre l'inactivité et l'arret
est de 15min. S'il se reconnecte à 12h16 alors l'expiration passe à 12h46.
Donc le délai varie entre 50 et 100% du timeout.
Quoi qu'il en soit le ticket est enregistré dans un cookie. C'est d'ailleurs
la raison d'être du sliding : evitez les alertes de sécurités pour les
postes qui sont configuré pour lever une boite de dialogue sur l'arrivée de
cookie.
De manière plus globale, pour une session, la persistence des infos
fluctuent : par défaut, l'état de session est conservé dans un cookie
suivant le délai défini dans
<sessionState. timeout="40". cookieless="true|false". />.
Vous remarquerez le flag cookieless : Pour les postes qui ne peuvent
accepter les cookies, il s'agit de faire transiter l'état de session comme
un ID dans l'url.
Enfin pour les informations non sensibles d'un point de vue sécurité, vous
pouvez utiliser des cookies permanents dans vos applications mais pour les
logins, je ne saurai trop vous le déconseiller.
L'article suivant semble une bonne source d'information sur le sujet
http://www.dotnetguru.org/articles/Sessions/Session.htm
HTH,
C.
"Oriane" <oriane@noemail.noemail> wrote in message
news:26F1D601-7E52-484D-8D13-A84232549B6A@microsoft.com...
Bon finalement je suis pas sûr d'avoir compris. Il y a apparemment une
notion de timeout pour la session et pour l'authentification.
Pour la session, cela veut dire qu'on doit se relogger après X minutes
d'inactivité.
Pour l'authentification, cela veut dire qu'on perd les infos
d'authentification après X minutes.
Jusque là, est-ce clair et surtout vrai ?
Donc je suppose que le timeout ci-dessous concerne l'authentification...
"Oriane" <oriane@noemail.noemail> a écrit dans le message de
news:372312DB-C55B-456B-95AB-AB0A78501425@microsoft.com...
Le paramètre que vous indiquez correspond effectivement au laps de temps au bout duquel un utilisateur doit se reconnecter (30 min par défaut en Asp .Net 2.0). C'est le délai d'expiration du ticket de sécurité. Attention avec le paramètre slidingExpiration (qui est vrai par défaut). Il demande à Asp .Net de ne mettre à jour le cookie que si >50% du temps (donc plus de 15min par défaut) s'est écoulé. Prenons l'exemple d'un utilisateur qui se connecte à 12h00. L'expiration d'origine est donc prévue pour 12h30. S'il se reconnecte à 12h14, l'expiration reste à 12h30... donc le délai entre l'inactivité et l'arret est de 15min. S'il se reconnecte à 12h16 alors l'expiration passe à 12h46. Donc le délai varie entre 50 et 100% du timeout.
Quoi qu'il en soit le ticket est enregistré dans un cookie. C'est d'ailleurs la raison d'être du sliding : evitez les alertes de sécurités pour les postes qui sont configuré pour lever une boite de dialogue sur l'arrivée de cookie.
De manière plus globale, pour une session, la persistence des infos fluctuent : par défaut, l'état de session est conservé dans un cookie suivant le délai défini dans <sessionState. timeout="40". cookieless="true|false". />. Vous remarquerez le flag cookieless : Pour les postes qui ne peuvent accepter les cookies, il s'agit de faire transiter l'état de session comme un ID dans l'url. Enfin pour les informations non sensibles d'un point de vue sécurité, vous pouvez utiliser des cookies permanents dans vos applications mais pour les logins, je ne saurai trop vous le déconseiller.
L'article suivant semble une bonne source d'information sur le sujet http://www.dotnetguru.org/articles/Sessions/Session.htm
HTH, C.
"Oriane" wrote in message news:
Bon finalement je suis pas sûr d'avoir compris. Il y a apparemment une notion de timeout pour la session et pour l'authentification. Pour la session, cela veut dire qu'on doit se relogger après X minutes d'inactivité. Pour l'authentification, cela veut dire qu'on perd les infos d'authentification après X minutes. Jusque là, est-ce clair et surtout vrai ? Donc je suppose que le timeout ci-dessous concerne l'authentification...
et merci de votre réponse. "Christophe RIT [MS]" a écrit dans le message de news:%
Bonsoir,
Le paramètre que vous indiquez correspond effectivement au laps de temps au bout duquel un utilisateur doit se reconnecter (30 min par défaut en Asp .Net 2.0). C'est le délai d'expiration du ticket de sécurité. Attention avec le paramètre slidingExpiration (qui est vrai par défaut). Il demande à Asp .Net de ne mettre à jour le cookie que si >50% du temps (donc plus de 15min par défaut) s'est écoulé.
Oui mais dans ce cas ce n'est pas ce paramètre que je veux contrôler. Que la session expire au bout de 30' me va très bien. Mais je veux que si l'internaute se reconnecte sur le même PC N jours après, il voit les informations de login/mot de passe préremplies, s'il a coché la casse "Rappelez vous de moi" (intégrée au composant Login de Asp.Net)
L'article suivant semble une bonne source d'information sur le sujet http://www.dotnetguru.org/articles/Sessions/Session.htm
Oui il parle de session mais apparemment ce n'est pas le sujet qui me concerne ! Cordialement
Bonjour Christophe,
et merci de votre réponse.
"Christophe RIT [MS]" <chrisrit@online.microsoft.com> a écrit dans le
message de news:%23pkoOuCeJHA.1272@TK2MSFTNGP04.phx.gbl...
Bonsoir,
Le paramètre que vous indiquez correspond effectivement au laps de temps
au bout duquel un utilisateur doit se reconnecter (30 min par défaut en
Asp .Net 2.0). C'est le délai d'expiration du ticket de sécurité.
Attention avec le paramètre slidingExpiration (qui est vrai par défaut).
Il demande à Asp .Net de ne mettre à jour le cookie que si >50% du temps
(donc plus de 15min par défaut) s'est écoulé.
Oui mais dans ce cas ce n'est pas ce paramètre que je veux contrôler. Que la
session expire au bout de 30' me va très bien. Mais je veux que si
l'internaute se reconnecte sur le même PC N jours après, il voit les
informations de login/mot de passe préremplies, s'il a coché la casse
"Rappelez vous de moi" (intégrée au composant Login de Asp.Net)
L'article suivant semble une bonne source d'information sur le sujet
http://www.dotnetguru.org/articles/Sessions/Session.htm
Oui il parle de session mais apparemment ce n'est pas le sujet qui me
concerne !
Cordialement
et merci de votre réponse. "Christophe RIT [MS]" a écrit dans le message de news:%
Bonsoir,
Le paramètre que vous indiquez correspond effectivement au laps de temps au bout duquel un utilisateur doit se reconnecter (30 min par défaut en Asp .Net 2.0). C'est le délai d'expiration du ticket de sécurité. Attention avec le paramètre slidingExpiration (qui est vrai par défaut). Il demande à Asp .Net de ne mettre à jour le cookie que si >50% du temps (donc plus de 15min par défaut) s'est écoulé.
Oui mais dans ce cas ce n'est pas ce paramètre que je veux contrôler. Que la session expire au bout de 30' me va très bien. Mais je veux que si l'internaute se reconnecte sur le même PC N jours après, il voit les informations de login/mot de passe préremplies, s'il a coché la casse "Rappelez vous de moi" (intégrée au composant Login de Asp.Net)
L'article suivant semble une bonne source d'information sur le sujet http://www.dotnetguru.org/articles/Sessions/Session.htm
Oui il parle de session mais apparemment ce n'est pas le sujet qui me concerne ! Cordialement
Oriane
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste inactif + de 30', il est déloggé et là il doit retaper ses informations d'authentification car le cookie a été effacé même s'il est permanent.
Donc la solution serait d'allonger le temps d'expiration de la session, même si ce n'est pas ce que je veux faire.
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste
inactif + de 30', il est déloggé et là il doit retaper ses informations
d'authentification car le cookie a été effacé même s'il est permanent.
Donc la solution serait d'allonger le temps d'expiration de la session, même
si ce n'est pas ce que je veux faire.
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste inactif + de 30', il est déloggé et là il doit retaper ses informations d'authentification car le cookie a été effacé même s'il est permanent.
Donc la solution serait d'allonger le temps d'expiration de la session, même si ce n'est pas ce que je veux faire.
Oriane
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste inactif + de 30', il est déloggé et là il doit retaper ses informations d'authentification car le cookie a été effacé même s'il est permanent.
Donc la solution serait d'allonger le temps d'expiration de la session, même si ce n'est pas ce que je veux faire.
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste
inactif + de 30', il est déloggé et là il doit retaper ses informations
d'authentification car le cookie a été effacé même s'il est permanent.
Donc la solution serait d'allonger le temps d'expiration de la session, même
si ce n'est pas ce que je veux faire.
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste inactif + de 30', il est déloggé et là il doit retaper ses informations d'authentification car le cookie a été effacé même s'il est permanent.
Donc la solution serait d'allonger le temps d'expiration de la session, même si ce n'est pas ce que je veux faire.
Oriane
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste inactif + de 30', il est déloggé et là il doit retaper ses informations d'authentification car le cookie a été effacé même s'il est permanent.
Donc la solution serait d'allonger le temps d'expiration de la session, même si ce n'est pas ce que je veux faire.
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste
inactif + de 30', il est déloggé et là il doit retaper ses informations
d'authentification car le cookie a été effacé même s'il est permanent.
Donc la solution serait d'allonger le temps d'expiration de la session, même
si ce n'est pas ce que je veux faire.
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste inactif + de 30', il est déloggé et là il doit retaper ses informations d'authentification car le cookie a été effacé même s'il est permanent.
Donc la solution serait d'allonger le temps d'expiration de la session, même si ce n'est pas ce que je veux faire.
Delf
On 19 jan, 16:57, "Oriane" wrote:
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste inactif + de 30', il est déloggé et là il doit retaper ses informat ions d'authentification car le cookie a été effacé même s'il est perma nent.
Ce cas n'est pas géré par le navigateur lui-même ?
Par exemple, il fait sur un site sur lequel j'ai un compte. Même 3 mois après ma dernière visite, le formulaire d'auth se prérempli car j'ai autorisé le navigateur à mémoriser ces informations.
-- Delf
On 19 jan, 16:57, "Oriane" <ori...@noemail.noemail> wrote:
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste
inactif + de 30', il est déloggé et là il doit retaper ses informat ions
d'authentification car le cookie a été effacé même s'il est perma nent.
Ce cas n'est pas géré par le navigateur lui-même ?
Par exemple, il fait sur un site sur lequel j'ai un compte.
Même 3 mois après ma dernière visite, le formulaire d'auth se
prérempli car j'ai autorisé le navigateur à mémoriser ces
informations.
En fait je crois comprendre ce qui se passe. Lorsque l'utilisateur reste inactif + de 30', il est déloggé et là il doit retaper ses informat ions d'authentification car le cookie a été effacé même s'il est perma nent.
Ce cas n'est pas géré par le navigateur lui-même ?
Par exemple, il fait sur un site sur lequel j'ai un compte. Même 3 mois après ma dernière visite, le formulaire d'auth se prérempli car j'ai autorisé le navigateur à mémoriser ces informations.
