Bonjour,
 
Je travaille sur un site web dont une barre d'identification est présente sur toutes les pages.
Il faut donc, que dès que l'utilisateur se log, une connection SSL soit utilisée.
C'est en effet très important, parceque c'est un site e-Commerce, sur lequel on peut payer par virement bancaire notamment, et sans indiquer les informations de virement. Donc si un petit malin se connecte avec le mot de passe d'un client, il peut commander en son nom des produits, et vu qu'il n'y a pas de limite de prix au panier...
 
Le site est assez lourd, et pour rémédier en partie à la lourdeur de la chose, j'ai suivi les indication de Microsoft au niveau de IIS : J'ai viré le support des variables de session.
 
De ce fait, lorsque l'utilisateur se log, je n'ai rien trouvé de mieu que de créer un cookie de session contenant son login/password, et je vérifie cette info à chaque chargement de page.
 
Seulement, à nouveau, ça demande donc du SSL tout le long de sa navigation. Je ne peux/veux pas utiliser de cookie encrypté, et ce pour diverses raisons (pas de support JS sur les navigateurs client, et si c'est le serveur qui envoie la version encryptée du cookie, ou qu'il est enregistré tel quel sur le PC du client, ça n'empêchera pas un petit malin de réutiliser cette valeur encryptée...)
 
Du coup, j'ai demandé aux admin de passer en SSL l'intégralité du site.
 
Seulement, évidement, le site est beaucoup plus lent tout à coup
 
Donc, je me demande comment faire pour pallier à ce problème.
Ce serait pas mal de ne pas avoir à renvoyer les infos du login/password à chaque page, mais j'ai du mal à imaginer une solution moins lourde que la gestion des variables de session (à ce moment, autant les réactiver), surtout que je suis loin d'être convaincu de la sécurité relative à ce type de système (il faudrait que je crée un cookie qui permette de vérifier que le cookie vient du bon PC, style en faisant un filtre sur l'IP, mais c'est insuffisant).
 
Vous avez une solution miracle ?
 
PS: Le site est en ASP, donc pas de solution style "letrucàlaconquimarchequenphp()"

heu pas de solution miracle la, enfin en asp!
A part les var de sessions, ouais je ne vois pas. Et encore, c'est pas super super sécure à mon sens...

 
si la personne est authentifiée, tu logges ds une base sql son id session qui est unique avec les droits (tu peux faire un objet dedié à ca, ou une implémentation différente).
 
L'idée est qu'a chaque page, son id session etant la même, tu peux travailler avec cet info, et tu checkes ds ta base si c ok.
 
Pour tes cookies, tu peux faire la meme chose, tu mets son id session, et qd il se reconnecte, tu peux comparer avec la base pour reprendre la ou il en etait et remettre a jour avec sa nouvelle id de session.
 
Les idées sont la, apres c peut etre pas mieux, a voir.
 

Moi j'ai pris la solution 2, puisque mettre un sessionid ou un login/pass, dans les deux cas, si ça transite tous les deux, n'importe quelle personne qui intercepte une trame peut se connecter au site avec un browser traffiqué.
 
Mais c'est justement ce point qui m'oblige a avoir SSL tout le long du site, et c'est ce qui m'ennuie

 
avec son idsession (qui est generée par le serveur & unique), meme en interceptant une trame, cet id ne pourra pas etre reproduit, donc ca va aller non ? (peut etre que mes lacunes reseau jouent contre moi)

Sisi, tu peux faire faire envoyer n'importe quel header à un browser traffiqué. Donc même un sessionid ne permet pas de s'assurer que c'est le client qui est à l'autre bout

 
mea culpa, je ne savais pas ...
[HS] tu as des infos la dessus ? j'ai qques projet à revoir ... [/HS]

Refait monter ce topic (ou envoie-moi un MP) à partir de mercredi prochain, je verrai pour te poster un exemple.

ca m'interesse pas mal aussi ca! On remonte le topic pour mercredi ca roule!

Groumpf J'ai intérêt à arriver à coder mon truc alors
 
En gros, il suffit d'écrire un client "telnet" capable de communiquer sur le port 80 en utilisant le protocole HTTP. (comptez pas sur moi pour faire un truc complet )
 
Ensuite, avec un navigateur, aller sur un site qui offre une première page, contenant un formulaire qui va permettre de mettre en session une variable. Ensuite, avec ce navigateur, sur ce même site, aller sur une page qui affiche le "POST" HTTP envoyé par le navigateur (ça peut être récupéré en sniffant les trames sur le réseau, ou en auditant un proxy).
 
Puis il suffit de copier ce POST dans le navigateur "à la main" afin qu'il renvoie le même, tout en faisant aller ce dernier sur une page spécifique qui affiche le contenu de la variable de session.
 
En toute logique, le navigateur "à la main" doit récupérer la variable de session, car en reproduisant exactement le POST de l'autre navigateur il sera pris pour l'autre.
Normalement, il suffit seulement de mettre la partie du post correspondant au cookie de session.

t'es sur de tout ca ? Ca me parait vachement simple quand meme

Ben ça va être l'occasion de vérifier. Mais à mon humble avis, c'est pas plus compliqué que ça. Les variables de sessions n'ont pas vocation à faire la sécurité du site.

tu peux nous faire une petite démo ?

Bah comme j'ai dit, pas avant mercredi, si j'ai le temps de glander au boulot, parcequ'il n'y à que mercredi que j'aurai un PC avec des outils de dev dessus et pas trop de boulot (là je développe avec NotePad chez un client...)

ah effectivement lol!
 
Bah a mercredi alors! :þ

alors alors ??

Ben alors j'y ai plus pensé et là j'ai du taff raz la gueule (à peine je met en ligne un site que j'ai la refonte d'un autre à faire... cette fois il faut passer en mode multi-entités un site web qui gère lui-même toute la logistique et l'éditique, je te raconte pas le nombre de trucs à modifier )

erf!
TU vas devenir un pro du query-replace! lol
 
Bon bah bon courage et nous oublie pas des que tu as du temps!

Sauf que c'est malheureusement plus compliqué que ça : tout ce qui était fixe et en dure va devenir dynamique. Sans parler du faire que toute l'éditique est faire via des Crystal Reports, et que c'est la vraie merde ce truc (quand ça marche, normalement faut plus y toucher parceque sinon ça marche plus après - même si on n'a rien fait d'autre qu'ouvrir le fichier - )

mouahahaha!
ASP rulaizzz!!

Je vois pas ce que le langage vient faire là-dedans
 
Je disais justement à un collègue qui bosse sur un ERP écrit en full C et Assembleur :
"C'est marrant le nombre de points communs qu'il y a entre les deux applis. Des grandes idées, et une mise en oeuvre dégueulasse, et un paramètrage à chier."
 
C'est marrant, il a tout de suite sû de quelle appli je parlais