Version imprimable
on y est presque :)
j'arrive a ajouter un produit dans le panier mais je ne peux pas modifier la quantité ou le supprimer du panier :(
que dois je mettre dans les règles de sortie (RewriteCond %{HTTPS} on)?
ne serait il pas plus simple de faire cette redirection vers le HTTPS avec un script PHP??
Bah oui, toujours cette histoire de redirection non suivie par Ajax. En fouillant dans la spécification W3C d'Ajax (XmlHttpRequest), on lit que la redirection est suivie si les "origines" sont dites identiques. Sauf que quand on lit ce que ça signifie, si on change de protocole (https => http), les origines ne peuvent pas être identiques. Donc c'est normal que la redirection ne se fasse pas.
En gros, j'ai l'impression que c'est tout /cart/* qui doit passer en HTTPS, mais ce n'est pas moi qui ai construit le site, je ne sais pas si c'est faisable. Mais si ça l'est, il faut modifier les règles ainsi :
Code:
2
3
4
5
6
eh non, ça ne marche pas, je ne peux pas rajouter un produit dans le panier!! :cry:
Oui, en effet, je suis un peu neuneu, ça pose toujours le problème du passage HTTP => HTTPS pour le script de mise au panier.
Question idiote : pourquoi est-ce que l'URL /cart/ doit être en HTTPS ?
En fait, ce qu'il faut identifier pour faire les bascules HTTP <=> HTTPS ce sont les changements de pages vues par l'utilisateur, pas les appels faits par les scripts embarqués dans ces pages vues (par ex. le script de mise dans le panier). Est-ce qu'il y a des signes distinctifs pour les pages vues par les utilisateurs ou pour les scripts utilisés dans ces pages vues ?
En fait, je me dis que le plus simple c'est de mettre tous les scripts JavaScript, Ajax, etc. dans un répertoire autre que /cart. Comme ça, on ne met pas de règle de redirection pour ces scripts, on ne met une règle que pour /cart qui ne contient plus que des pages vues.
c'est pas du tout bête et tu as entièrement raison. c'est moi qui suis bête d'avoir mis tout le dossier 'cart' en https!! :DCitation:
Question idiote : pourquoi est-ce que l'URL /cart/ doit être en HTTPS ?
je pense que la solution serait de choisir entre ces 2 options:Citation:
En fait, ce qu'il faut identifier pour faire les bascules HTTP <=> HTTPS ce sont les ... Est-ce qu'il y a des signes distinctifs pour les pages vues par les utilisateurs ou pour les scripts utilisés dans ces pages vues ?
1- deplacer les dossiers 'ajax' dans un autre dossier où la règle https ne s'applique pas.
2- appliquer une règle https UNIQUEMENT pour les fichiers concernés (/cart/checkout.php, /account/login.php, /account/contact-us.php, ...)
je te laisse choisir la meilleure option ;)
mais la question que je me pose est:
est ce securisé d'etre sur une page https et faire des appels de fichiers non sécurisés en utilisant Ajax!
En réfléchissant au calme, ma suggestion de mettre les scripts JS en dehors de /cart n'a pas plus de sens que le reste car la règle de passage HTTPS => HTTP posera problème également.
En gros, je vois deux cas simples :
- Sécuriser en HTTPS un répertoire en entier et mettre dans ce répertoire l'ensemble des fichiers JS, images, CSS, etc. intégrés dans les pages protégées.
- Ma première suggestion : avoir des URL reconnaissables à 100% pour les fichiers intégrés dans les pages. Comme ça, on peut mettre une exception pour dire de ne pas forcer la redirection vers HTTP de ces fichiers.
Les autres options nécessairement poseront problème, je pense.
cela va me causer beaucoup de travail étant donné que je vais devoir refaire toute l'ergonomie des fichiers... :(Citation:
Sécuriser en HTTPS un répertoire en entier et mettre dans ce répertoire l'ensemble des fichiers JS, images, CSS, etc. intégrés dans les pages protégées.
c'est ce que j'avais fait pour un ancien site que j'ai crée, j'ai toujours mis href="https://" pour les pages sécurisées, mais je t'avoue que je n'ai pas trop aimé cette façon de faire. je pensais pouvoir le faire proprement!Citation:
Ma première suggestion : avoir des URL reconnaissables à 100% pour les fichiers intégrés dans les pages. Comme ça, on peut mettre une exception pour dire de ne pas forcer la redirection vers HTTP de ces fichiers.
et si j'opte pour une redirection vers HTTPS en PHP?
Ca se tente, mais il faudra gérer côté code le repassage en HTTP, donc mettre des href="http://..." :aie: M'est idée que ça ne va pas te plaire :roll:
je vais reflechir a une méthode plus propre et te tiens au courant très prochainement ;)
Merci pour tout!
Bonsoir,
voici comme convenu une solution qui marche mais qu'a moitié :) je t'avoue que je me suis arraché les cheveux pour comprendre ce qui ne va pas mais impossible de trouver le problème!
mais la encore une fois mes fichiers ajax ne fonctionnent pas! :bug:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24// tableau des pages qui doivent s'exécuter en https $pages_https = array("/help/contact-us.php", "/account/create.php", "/account/index.php", "/account/login.php", "/cart/checkout.php"); // pas en local if(stripos($_SERVER['SERVER_NAME'], ".localhost") === false) { if($_SERVER["HTTPS"] != "on") { if(in_array($_SERVER['PHP_SELF'], $pages_https)) { header("HTTP/1.1 301 Moved Permanently"); header("Location: https://www.". $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI']); exit(); } } else { if(!in_array($_SERVER['PHP_SELF'], $pages_https)) { header("HTTP/1.1 301 Moved Permanently"); header("Location: http://www.". $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI']); exit(); } } }
Curieusement lorsque je vire le else (orange) de la sortie du https, le tout fonctionne bien!
en quoi est ce que la partie orange peut gêner?????!! as tu une idée?
je me suis cassé la tete toute la journée mais impossible de comprendre. aurais tu une idée d'où le problème pourrait provenir???
Là, tu as refait exactement ce que faisaient les règles Apache et ça ne fonctionne pas exactement pour les mêmes raisons. Ce qu'il faut c'est ne pas forcer la redirection pour les ressources embarquées dans les pages (images, CSS, JavaScript, etc.) et appelées par Ajax mais là on retombe sur les questions que je posais en début de semaine, je vais me répéter : peut-on faire la différence de manière certaines (en regardant seulement les URL) entre les URL qui renvoient du code HTML et les autres ? Si on ne peut pas, le seul moyen que je vois c'est faire ce qui ne te plaisait pas, à savoir gérer dans le code des href en http ou https.
Je suis désolé, mais je ne comprends pas ce que tu veux dire par ça :(Citation:
peut-on faire la différence de manière certaines (en regardant seulement les URL) entre les URL qui renvoient du code HTML et les autres ?
Il y a des URL qu'on souhaite rediriger (/cart/ par exemple) et d'autres qu'on ne souhaite pas rediriger (les URL appelées par Ajax par exemple). Comment faire ? Ben si on sait faire la différence entre les trucs à rediriger et les autres simplement en regardant les URL, on a gagné. Mais si on ne sait pas, on n'a pas gagné et il faut gérer la redirection par des URL absolues dans le code HTML (URL absolues calculées par du PHP ou pas, peu importe).
On peut dire par exemple que ces seules pages sont celles se terminant par .html mais ce n'est pas le cas : par exemple, la page de login se termine en .php. Alors pourquoi ne pas dire qu'il ne faut rediriger que les URL se terminant en .html et .php ? Ca ne marchera pas parce que malheureusement ton site fait des appels Ajax vers des URL se finissant en .php qu'il ne faut justement pas rediriger...
En fait, je ne sais pas trop comment expliquer plus simplement :aie:
d'accord, je comprends mieux. mais il y a un truc que je ne saisis pas!
si je force uniquement la page /cart/checkout.php, pourquoi est ce que les appels Ajax de cette page sont aussi redirigés? moi j'ai créé une action UNIQUEMENT pour la page, pas ces appels Ajax!
et sinon pour répondre a ta question. ça ne sera pas possible d'identifier et de différencier les pages. elles sont TOUTES en .php, par contre TOUS les fichiers appelés par ajax, sont dans un dossier nommé 'ajax', je ne sais pas si cela pourrait aider!
sinon je viens de trouver une solution qui est "potable" :)
j'appelle la fonction force_https() dans les pages a sécuriser, et force_http() dans les autres pages...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19function force_https() { if(stripos($_SERVER['SERVER_NAME'], ".localhost") === false) { if($_SERVER["HTTPS"] != "on") { //header("HTTP/1.1 301 Moved Permanently"); header("Location: https://www.". $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI']); exit(); } } } function force_http() { if(stripos($_SERVER['SERVER_NAME'], ".localhost") === false) { if($_SERVER["HTTPS"] == "on") { //header("HTTP/1.1 301 Moved Permanently"); header("Location: http://www.". $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI']); exit(); } } }
qu'en penses tu?
A défaut, ça me semble acceptable.
hehe, on a fait le tour de l'horizon et on revient a une solution plus ou moins artisanale :D
en utilisant mon script, quel est la meilleure façon de protéger tout un dossier? dans mon cas ça sera www.site.com/admin
j'aimerais que toute la partie admin soit en https.
d'abord, est ce bien utile? ou devrais juste mettre une protection avec un htaccess?
https et une protection par .htaccess comme tu dis n'ont pas du tout les mêmes objectifs de sécurité. Le HTTPS sert à chiffrer la connexion entre le navigateur et le serveur de manière à ce que seuls ces deux programmes sachent ce qu'ils s'échangent. On utilise HTTPS pour la confidentialité des données. En HTTPS de base, il n'y a pas d'authentification même si c'est possible. De son côté, une authentification basique est une protection par mot de passe relativement simple sans chiffrement de la connexion. Le défaut de l'authentification est que le login et le mot de passe sont envoyés à chaque requête sans véritable chiffrement : si on capture le flux entre le navigateur et le serveur, il faut 30 secondes montre en main pour retrouver ce login et mot de passe. Du coup, on préfère généralement utiliser l'authentification Digest plus costaud mais c'est plus difficile à mettre en place, ou plus simplement mettre HTTPS + authentification basique.
Pour protéger ton /admin, je ferais donc les 2 : authentification (basique minimum) + HTTPS redirigé par .htaccess. Mais le souci c'est que tu ne pourras pas forcer le passage HTTP => HTTPS sur un dossier protégé par .htaccess, je crois. A tester.