ca serait vraiment génial.
tout comme le fait de ne pas être redirigé vers http:// quand la session https:// est invalidée (mais c'est déjà dans le suivi ca.)

[ Répondre ]

Si on ajoute un cookie (un de plus...) on doit pouvoir faire un truc genre

RewriteCond %{HTTP_COOKIE} ^.*https.*$
RewriteCond %{HTTP_COOKIE} !^.*nohttps.*$
RewriteCond %{SERVER_PORT} !443
RewriteRule ^(.*)$ https://linuxfr.org/$1 [R,L]

Et pareil dans l'autre sens pour les allergiques au https

RewriteCond %{HTTP_COOKIE} ^.*nohttps.*$
RewriteCond %{SERVER_PORT} 443
RewriteRule ^(.*)$ http://linuxfr.org/$1 [R,L]

[ Répondre ]

Le problème, c'est que quand on suit un lien en http (alors qu'on est loggué en https), le navigateur envoie le cookie avant même qu'on puisse faire la redirection en https...

Il me paraît vital (du point de vue de la sureté) que l'identification en https produise un "cookie sécure" (le dernier paramètre de l'en-tête Set-Cookie, cf http://wp.netscape.com/newsref/std/cookie_spec.html(...)). Et là, la suivation (filature?) d'un lien http envoie sur une page où l'on n'est pas identifié, et dans ce cas pas de redirection possible :(

En conclusion, il faut choisir entre les deux : soit un cookie sécurisé, soit une redirection. Deux options, non cumulables.

Petite parenthèse : là où c'est gênant, c'est quand on ne voit pas le lien http, inclus dans une page d'un autre site, par exemple dans les pages "en cache" de google. Vous avez essayé? C'est troublant, cette boîte de login déjà remplie... http://www.google.com/search?q=cache:RdsCAMe2x9sJ:linuxfr.org/forum(...) ...mais là c'est une autre histoire!

[ Répondre ]

https://linuxfr.org/tracker/351.html

[ Répondre ]

A partir de maintenant, les utilisateurs qui se connectent en https recevront des cookies secure (ie qui ne sont envoyées que dans du https, pas dans du http), ainsi qu'un cookie https. Ce dernier sert à faire la redirection depuis le http vers le https.

[ Répondre ]