[demental]

Perso je préfère ménager la chèvre et le choux.
Si je ne me trompe pas, ne pas baser son identifiant de session sur l'adresse IP du client (de toute façon à moins de monter son propre système de session on n'a pas trop le choix sur un mutu), n'est il pas une faille potentielle car un utilisateur capable d'intercepter l'identifiant de session d'un utilisateur connecté peut prendre son identité et l'utiliser sur une autre machine ?

Donc dans mon cas je n'interdis pas l'accès aux utilisateurs d'aol ou autres qui passent par un proxy, mais je les incite à prendre contact avec l'équipe de support, qui derrière leur indique la marche à suivre pour pouvoir se connecter sans problème.
Le tout est d'étudier sa stratégie pour ne pas utiliser les sessions avant que le client aie été accroché.

[Abogil]

Peut-être un début d'explication aux problèmes de sessions d'aol : http://www.humourenpj.net/pj/aohell.screen.jpg

[Noxiweb]

En quoi est-ce une "grosse faute" ?

Tout simplement parce que ça bug de partout, ça s'appelle du bon sens, tu sais la réputation d'AOL auprès des développeurs pro de n'importe quel pays n'est pas à faire que ça soit sur ce soucis ou sur ses soucis d'e-mails aussi vieux que l'existence d'Internet.

Il n'y a aucune RFC qui indique que ça doit être le cas.
Et au contraire, AOL ou les entreprises qui ont de tels proxys ont d'excellentes raisons techniques de faire ainsi pour cumuler les caches disponibles sur les differents proxys d'une même grappe au lieu de dupliquer le contenu partout.

Tu as tout à fait raison, ce n'est indiqué nul part et libre à chaqu'un de faire du travail totalement nul ou super bien, c'est comme dans tous les domaines, il y a en a bien qui héberge des sites pros chez Free, donc pourquoi AOL ne pourrait pas créer des abérations techniques.
Et les "excellentes raisons" pour un FAI en crise ils ont tout à fait raison de compter l'argent même arrivé au stade du millier d'Euros.

Tu "supposes" que, parce que c'est vrai dans la plupart des cas de ton expérience (limitée), c'est généralisable, et tu te plains en suite que ça ne marche pas à 100%

Attention aux préjugés jeune pouce, je ne sais pas qui suppose mal mais par manque de chance pour toi mon expérience limitée fait que je ne suis pas que développeur pro, mon métier principal fait que je travaille dans les locaux technique d'un FAI.

Et d'ailleurs julpom a le problème avec des utilisateurs qui n'ont rien à voir avec AOL:

Et oui comme quoi il n'y a pas que AOL ...

[Spamplemousse]

je veux surtout préciser que la faute incombe bien à AOL et non aux développeurs car à chaque requête faite par un abonné AOL sous son navigateur un choix de proxy va être fait aléatoirement ce qui est la grosse faute

En quoi est-ce une "grosse faute" ?

Il n'y a aucune RFC qui indique que ça doit être le cas.
Et au contraire, AOL ou les entreprises qui ont de tels proxys ont d'excellentes raisons techniques de faire ainsi pour cumuler les caches disponibles sur les differents proxys d'une même grappe au lieu de dupliquer le contenu partout.

Tu "supposes" que, parce que c'est vrai dans la plupart des cas de ton expérience (limitée), c'est généralisable, et tu te plains en suite que ça ne marche pas à 100%... exactement comme les gens qui ne connaissent qu'Internet Explorer et ensuite se plaignent parce que leur site ne s'affiche pas correctement sous Firefox/Opera/Safari, etc.

La grosse faute c'est de verrouiller les sessions HTTP (couche applicative) sur une information de couche réseau, soit 2 couches au-dessous dans le modèle OSI. Ca c'est une grosse faute par contre -- une violation du principe d'indépendance des couches du modèle OSI -- tout comme les gens qui développent des sites web sans lire les standards et uniquement d'après le résultat observé sous Internet Explorer...

Et d'ailleurs julpom a le problème avec des utilisateurs qui n'ont rien à voir avec AOL:

Malheureusement la réponse est non :-/ Il n'y a pas que les gens de chez AOL qui posent probleme avec les session, les gens qui sont chez telkom/saix.net ont le même souci avec un proxy à la con.

[Noxiweb]

Encore un qui n'a rien compris...

Le problème n'a rien à voir avec AOL ou son navigateur web (qui n'est autre que l'Internet Explorer déjà installé et disponible sur la machine, et "embeddé" sans ses barres de menu), mais avec les utilisateurs qui accèdent à Internet via des grappes de serveurs proxy.

En fait ce qu'il a dit est quand même correct, c'est indirectement en rapport avec le navigateur AOL car un abonné AOL qui va passer par ce navigateur va passer par les proxy clusterisés et le même abonné AOL qui va passer sous IE non.

Maintenant, rien ne vous empêche de faire n'importe quoi en rendant votre site incompatible avec une partie du reste de l'Internet... vous pouvez exiger que les gens utilisent Windows et Internet Explorer si ça vous chante dans le même genre, uniquement par flemmardise pour éviter de rendre votre site compatible avec Firefox et/ou Opera et/ou Safari et/ou les serveurs proxy tels que ceux d'AOL ou des grandes entreprises...

Rendre indisponible le site en effet un peu trop radical (perso j'informe juste les visiteurs) mais je veux surtout préciser que la faute incombe bien à AOL et non aux développeurs car à chaque requête faite par un abonné AOL sous son navigateur un choix de proxy va être fait aléatoirement ce qui est la grosse faute, ça ne devrait être fait qu'à la 1ère requête et ensuite passer toujours par le proxy en question car en l'état actuelle des choses l'abonné va tout le temps changer d'adresse IP vis à vis d'Internet donc ça ne tiendrait qu'à eux de faire correctement les choses, d'autres boîtes l'ont fait sans soucis, les autres FAI, Orange etc mais surtout OVH justement, imagine si en allant sur un site en mutu tu changeais de serveur sur le cluster à chaque page, les sessions auraient pas finit de sauter.

[Spamplemousse]

vu que les sites web utilisent un protocol HTTP, et à ma connaissance, aucun site utilise un protocol AOL://, bah vous prennez pas la tête :
IF AOL_BROWSER ECHO "Merci d'utiliser un vrai navigateur tel que Firefox, Mozilla, Opera"

Encore un qui n'a rien compris...

Le problème n'a rien à voir avec AOL ou son navigateur web (qui n'est autre que l'Internet Explorer déjà installé et disponible sur la machine, et "embeddé" sans ses barres de menu), mais avec les utilisateurs qui accèdent à Internet via des grappes de serveurs proxy.

Et d'ailleurs julpom a eu le problème avec des utilisateurs saix.net ...
et on pourrait citer n'importe quelle grande entreprise qui n'offre un accès au web qu'à travers des serveurs proxy qui travaillent en cluster.

Maintenant, rien ne vous empêche de faire n'importe quoi en rendant votre site incompatible avec une partie du reste de l'Internet... vous pouvez exiger que les gens utilisent Windows et Internet Explorer si ça vous chante dans le même genre, uniquement par flemmardise pour éviter de rendre votre site compatible avec Firefox et/ou Opera et/ou Safari et/ou les serveurs proxy tels que ceux d'AOL ou des grandes entreprises...

A chaque idiotie du genre, vous vous privez de 5 à 15% supplémentaires de visiteurs qui ne pourront pas accéder à votre site -- et qui ne s'en porteront pas plus mal probablement...

[Abogil]

IF AOL_BROWSER ECHO "Merci d'utiliser un vrai navigateur tel que Firefox, Mozilla, Opera".

Tout à fait d'accord.

[freeraid]

Bonjour,

vu que les sites web utilisent un protocol HTTP, et à ma connaissance, aucun site utilise un protocol AOL://, bah vous prennez pas la tête :

IF AOL_BROWSER ECHO "Merci d'utiliser un vrai navigateur tel que Firefox, Mozilla, Opera"

Si tout le monde fait ça, dans le monde entier (bah quoi avec la mondialisation, on pourrait peut etre faire entrer cette norme) aol finirait surement par abandonner leurs conneries.

[julpom]

Et ceux qui posent problème, ce ne sont pas les utilisateurs de tels systèmes, mais les programmeurs/administrateurs de systèmes de gestion de sessions HTTP qui ne respectent pas le principe d'indépendance des couches du modèle OSI et introduisent artificiellement dans leur architecture des dépendances entre la couche applicative et la couche réseau...

certes :/

Pour les gens qui ont le même problème, je confirme que l'utilisation de
http://forum.ovh.net/showpost.php?p=59430&postcount=27
résoud le probleme des sessions avec AOL & co.

[Spamplemousse]

Il n'y a pas que les gens de chez AOL qui posent probleme avec les session, les gens qui sont chez telkom/saix.net ont le même souci avec un proxy à la con.

Le problème se reproduira avec n'importe quelle grande entreprise qui n'offre pas un accès direct à Internet à ses employés mais passe par une grappe de serveurs proxy intermédiaires...

Et ceux qui posent problème, ce ne sont pas les utilisateurs de tels systèmes, mais les programmeurs/administrateurs de systèmes de gestion de sessions HTTP qui ne respectent pas le principe d'indépendance des couches du modèle OSI et introduisent artificiellement dans leur architecture des dépendances entre la couche applicative et la couche réseau...

[julpom]

Pour répondre à la question du début, je pense que pour indiquer à php que les sessions ne doivent pas se baser sur l'ip du client mais sur des cookies uniquement, il faut mettre en début de script :

ini_set('session.use_only_cookies', true);

Normalement, ça résout le problème avec AOL.
Je n'ai jamais testé. Si quelqu'un pouvait confirmer ce que je raconte, ce serait sympa

Malheureusement la réponse est non :-/ Il n'y a pas que les gens de chez AOL qui posent probleme avec les session, les gens qui sont chez telkom/saix.net ont le même souci avec un proxy à la con.

[Moof26]

Pour répondre à la question du début, je pense que pour indiquer à php que les sessions ne doivent pas se baser sur l'ip du client mais sur des cookies uniquement, il faut mettre en début de script :

ini_set('session.use_only_cookies', true);

Normalement, ça résout le problème avec AOL.
Je n'ai jamais testé. Si quelqu'un pouvait confirmer ce que je raconte, ce serait sympa

[Spamplemousse]

On parle à nouveau de pertes de sessions sur les hébergements mutualisés ici:
http://forum.ovh.net/showthread.php?t=12140

[teopath]

Pour clore, je vais quand même expliquer comment j'ai fait.

Lorsque le visiteur rentre son pseudo et son mdp, s'il est identifié, une session est ouverte et une variable de session est définie avec l'ID du membre dans la table des membres, mais parallélement l'ID est cryptée et chargée deans une seconde variable avec un nom pas trop évocateur et est passée à travers tous les liens internes par méthode GET.

Pour chaque page, la variable de session est testée, si elle est présente elle est récupérée, si elle est absente, on décrypte la variable de l'URL.

Donc si le visiteur ne vient pas de chez AOL, la variable de l'URL sert à faire beau et à amuser le hacker potentiel

Si le visiteur vient de chez AOL ou si il n'y a pas de variable de session, on se sert de la variable de l'URL.

Tout ceci n'est en fait qu'un exercice de style, car il s'agit d'une messagerie, donc sans grand secret et si un hacker arrive a entrer il n'y aura pas mort d'homme.

Ceci dit, grand merci à tous, j'ai découvert certaines choses, d'autres me sont restées obscures car ce n'est pas ma partie et il me manque des bases.
L'important c'est que je sois arrivé à bout de mon problème, même si c'est en utilisant des chemins détournés

[bbq]

Oui, merci

[Abogil]

Un grand merci Spamplemousse pour toutes ces réponses très claires et qui m'ont appris un domaine que je connaissais mal.

[Spamplemousse]

Etant donné qu'il n'y a qu'un seul login AOL pour la connexion avec AOL ADSL et sachant que sur un micro, il peut y avoir plusieurs login windows :

• Si l'enfant utilise le navigateur AOL pour accéder à internet, je veux bien admettre que le contrôle parental est parfait.
• Mais que se passe-t'il lorsque l'enfant utilise directement le navigateur IE ou Firefox qui EUX ne passent par les caches AOL et ne passent donc pas par le contrôle parental d'AOL.

Tu n'as pas compris... si le contrôle parental est activé (par exemple compte utilisateur en catégorie "Enfant"), la machine n'a plus d'accès Internet (IP) direct, donc les navigateurs externes (qui ne passent pas par les proxys) ne fonctionnent plus du tout, et aucune application (y compris Peer2Peer) ne fonctionne.

Lorsqu'il y a partage de connexion Internet, la situation est prévue et AOL offre une solution technique pour cela... soit AOL9 est installé sur chaque PC, soit le module "IAC" (Internet Access Control) fourni par AOL au mot-clé "Contrôle Parental" suffit pour ceux qui ne veulent pas installer AOL9 partout.

Lorsqu'on lance un navigateur externe, le trafic web est alors redirigé sur une grille d'authentification via un login/mot de passe AOL, de façon totalement similaire aux bornes "hotspot" d'accès WiFi payantes dans les hôtels ou les aéroports.

Je n'expliquerai pas comment ça fonctionne techniquement, je n'ai pas que ça à faire non plus... Si tu as déjà essayé d'utiliser un accès réseau payant dans une chambre d'hôtel, tu sais que tu as l'impression d'avoir accès à Internet (tu récupères une IP via DHCP, etc.) mais en pratique dès que tu essaies d'accéder à n'importe quelle page web, tu est redirigé vers une grille de login qui te demande ton numéro de chambre et te fait accepter les conditions générales d'utilisation du service et le prix à la journée... ce qui débloque ensuite réellement l'accès IP pour ton poste spécifiquement.

Il suffit de lire les commentaires de la presse ou des associations de protection de l'enfance (qu'on peut difficilement soupçonner de partialité):

http://www.01net.com/editorial/30857...role-parental/

http://www.e-enfance.org/e-enfance/i...cces_internet/

[Abogil]

Oui, merci beaucoup pour l'explication, je ne suis pas ingénieur mais je prend la peine de lire ce qu'écrivent les autres.

C'était justement le sujet du thread : Les incompatibilités de AOL avec les sessions PHP

Et ce que tu me décris, c'est justement les sessions PHP

A quoi avais tu donc l'impression de répondre depuis le début ?

Oui, car les changements permanents d'adresse IP m'ont beaucoup géné il y a 18 mois. Mais, malheureusement, je ne me rappelle plus quels problèmes cela me posait. Mais à l'époque cela m'avait beaucoup géné. Je suis désolé d'être intervenu au début de ce POST.

Justement Shadow aok a écrit :

Les sessions php marchent très bien avec AOL, il ne faut juste pas faire de vérifications ou se baser sur l'ip car la leur changer quasiment à chaque page qu'ils visitent.

Actuellement des personnes se connectent à mes sites via le navigateur AOL et je n'ai pas de problème avec la méthode que j'ai citée plus haut.

Par contre, je n'ai pas réussi à trouver sur mon micro où se trouvait ces cookies utilisés pour les sessions et par session_start();

[teopath]

Tu n'a pas à te préocuper de placer un cookie sur le micro de celui qui accède à ton site.

Il te suffit d'utiliser les sessions => http://fr2.php.net/manual/fr/function.session-start.php

Commence tes scripts PHP par un session_start();
Transfère des variables via $_SESSION['toto'] = "tutu";
Récupère tes variables dans un autre script via $toto = $_SESSION['toto'];

Oui, merci beaucoup pour l'explication, je ne suis pas ingénieur mais je prend la peine de lire ce qu'écrivent les autres.

C'était justement le sujet du thread : Les incompatibilités de AOL avec les sessions PHP

Et ce que tu me décris, c'est justement les sessions PHP

A quoi avais tu donc l'impression de répondre depuis le début ?

[Abogil]

Au final, pour la solution de mon problème, j'ai essayé de placer un cookie, çà j'y arrive, j'arrive à écrire ce que je veux dedans, j'arrive à vérifier sa présence, j'arrive à tester si telle valeur est dadans, mais après trois jour de lutte je n'arrive à récupérer directement la valeur.

Tu n'a pas à te préocuper de placer un cookie sur le micro de celui qui accède à ton site.

Il te suffit d'utiliser les sessions => http://fr2.php.net/manual/fr/function.session-start.php

Commence tes scripts PHP par un session_start();
Transfère des variables via $_SESSION['toto'] = "tutu";
Récupère tes variables dans un autre script via $toto = $_SESSION['toto'];

[Abogil]

Lorsqu'un abonné AOL s'authentifie pour démarrer une session réseau (via AOL9 par exemple), AOL s'aperçoit que le pseudo (login) en question est soumis à contrôle parental, et donc l'accès Internet direct (IP) est désactivé... une ACL sur les serveurs d'accès ne permet d'accéder qu'au proxy/cache HTTP AOL, qui lui n'autorise l'accès qu'aux sites web compatibles avec la catégorie de contrôle parental associée au pseudo (enfant ou adolescent)

Etant donné qu'il n'y a qu'un seul login AOL pour la connexion avec AOL ADSL et sachant que sur un micro, il peut y avoir plusieurs login windows :

• Si l'enfant utilise le navigateur AOL pour accéder à internet, je veux bien admettre que le contrôle parental est parfait.
• Mais que se passe-t'il lorsque l'enfant utilise directement le navigateur IE ou Firefox qui EUX ne passent par les caches AOL et ne passent donc pas par le contrôle parental d'AOL.

J'en déduis qu'il y a un léger trou à combler.

[teopath]

Pas du tout... le contrôle parental est simplement la raison pour laquelle AOL conserve ses serveurs proxy/cache HTTP (réponse de la question d'Abogil) et autoconfigure Internet Explorer (incrusté à l'intérieur d'AOL9) pour utiliser les proxy/cache HTTP pour accéder au web.

Mais ça n'a rien à voir avec l'origine des incompatibilités remarquées sur les serveurs mutualisés OVH: même des comptes utilisateurs AOL en catégorie "Adulte" (contrôle parental désactivé) auront le problème, de même que les utilisateurs en entreprise qui n'autorisent l'accès à Internet que via une grappe (cluster) de proxy/cache qui travaillent en parallèle.

Au final, pour la solution de mon problème, j'ai essayé de placer un cookie, çà j'y arrive, j'arrive à écrire ce que je veux dedans, j'arrive à vérifier sa présence, j'arrive à tester si telle valeur est dadans, mais après trois jour de lutte je n'arrive à récupérer directement la valeur.

Suis un peu neu²

De toute façon AOL est encore foutu d'avoir inventé un truc pour bloquer les cookies

mais il faudrait que quelqu'un d'OVH connaissant l'architecture technique précise de leurs hébergements mutualisés nous en dise plus...

Est ce que chez OVH quelqu'un connait l'architecture technique ? A voir tous les problèmes avec les emails, je crois qu'on peut en douter

Je vais donc crypter mes ID et les passer par méthode GET, j'espère qu'il n'y a pas encore un truc bizarre chez AOL

[Spamplemousse]

Si je comprends bien (mais rien n'est moins sur), dans mon cas c'est le controle parental d'AOL le fauteur de troubles ?

Pas du tout... le contrôle parental est simplement la raison pour laquelle AOL conserve ses serveurs proxy/cache HTTP (réponse de la question d'Abogil) et autoconfigure Internet Explorer (incrusté à l'intérieur d'AOL9) pour utiliser les proxy/cache HTTP pour accéder au web.

Mais ça n'a rien à voir avec l'origine des incompatibilités remarquées sur les serveurs mutualisés OVH: même des comptes utilisateurs AOL en catégorie "Adulte" (contrôle parental désactivé) auront le problème, de même que les utilisateurs en entreprise qui n'autorisent l'accès à Internet que via une grappe (cluster) de proxy/cache qui travaillent en parallèle.

[Homer Jay]

il faut s'assurer (comme indiqué dans la note technique) que la répartition de charge ne se fait pas en fonction de l'adresse IP du client web,

Ha oui, ça donnerait des situations «intéressantes». Et ça sexpliquerait bien des choses.

[teopath]

Lorsqu'un abonné AOL s'authentifie pour démarrer une session réseau (via AOL9 par exemple), AOL s'aperçoit que le pseudo (login) en question est soumis à contrôle parental, et donc l'accès Internet direct (IP) est désactivé... une ACL sur les serveurs d'accès ne permet d'accéder qu'au proxy/cache HTTP AOL, qui lui n'autorise l'accès qu'aux sites web compatibles avec la catégorie de contrôle parental associée au pseudo (enfant ou adolescent).

Si je comprends bien (mais rien n'est moins sur), dans mon cas c'est le controle parental d'AOL le fauteur de troubles ?

[Spamplemousse]

Il me semble pourtant que Orange (Wanadoo), Free, Neuf, Cegetel, etc. offrent l'option du contrôle parental. Option qui est très souvent pris par les abonnés d'Orange. Ce contrôle parental n'empêche pas ces FAI de fournir une adresse IP fixe durant toute la session.

Orange (du temps de Wanadoo France, cf. proxy.wanadoo.fr), Noos (proxy.noos.fr) et Free (proxy.free.fr) ont des serveurs proxy HTTP... (et d'autres FAI aussi)
mais qui ne font pas de contrôle parental, ils se contentent d'accélérer les requêtes HTTP des abonnés bas débit -- seul AOL utilise son infrastructure proxy/cache HTTP pour fournir un service de contrôle parental inviolable à ses abonnés.

Du coup, et vu l'avènement du haut débit, tous les FAI ont supprimé leurs proxys (ou arrêtent de communiquer sur leur existence) car il n'est plus vraiment utile d'accélérer l'accès au web...

proxy.wanadoo.fr, proxy.noos.fr et proxy.free.fr existent toujours (au moins dans le DNS), même si personne n'est au courant de leur existence ni de comment les utiliser.

D'ailleurs, lors du changement de marque wanadoo.fr => orange.fr de juin dernier,
France Telecom a "oublié" de déclarer proxy.orange.fr -- seul proxy.wanadoo.fr existe toujours dans le DNS, ce qui prouve bien qu'ils abandonnent toute forme de communication sur le sujet.

De toute façon ils ne servent plus vraiment à grand chose puisqu'ils ne font qu'accélérer l'accès au web pour les connexions bas débit (ce qui ne sert plus à grand monde) et rien d'autre.

En plus cela fait des serveurs supplémentaires à gérer -- de la même façon que les FAI sont en train de supprimer progressivement les serveurs de news NNTP/Usenet actuellement, car c'est pénible à administrer et quasiment plus personne n'utilise ça -- les gens intéressés peuvent toujours aller sur Google Groups.

Aucun des FAI que tu cites (hors AOL) ne fournit de solution de contrôle parental sur son réseau -- ils se contentent de fournir un logiciel que leurs abonnés peuvent télécharger et installer volontairement pour verrouiller leur PC localement, et évidemment ce sont les enfants qui sont les premiers à savoir comment désinstaller ou court-circuiter ce logiciel.

Pire: ces logiciels de contrôle parental à installer sur le poste client n'existent qu'en version PC et Mac -- or, il y a de plus en plus de périphériques (consoles de jeu, PSP, assistants personnels/PDA, PC sous Linux, etc.) munis d'un navigateur web capable de se connecter sur Internet et d'accéder au web, et donc pour lesquels ces FAI n'ont absolument aucun système de contrôle parental à proposer.

Il n'y a qu'AOL pour fournir un contrôle parental impossible à "hacker" car il n'y a absolument rien d'installé sur le PC de l'abonné -- toutes les opérations de contrôle parental sont effectuées sur les serveurs d'accès et les serveurs proxy/cache AOL.

Lorsqu'un abonné AOL s'authentifie pour démarrer une session réseau (via AOL9 par exemple), AOL s'aperçoit que le pseudo (login) en question est soumis à contrôle parental, et donc l'accès Internet direct (IP) est désactivé... une ACL sur les serveurs d'accès ne permet d'accéder qu'au proxy/cache HTTP AOL, qui lui n'autorise l'accès qu'aux sites web compatibles avec la catégorie de contrôle parental associée au pseudo (enfant ou adolescent).

Une entreprise qui souhaite contrôler l'accès à Internet de ses employés peut mettre en oeuvre une architecture technique identique: pas d'accès IP direct, mais accès au web via des serveurs proxy/cache HTTP intermédiaires.

Avantage: il est possible de demander une authentification utilisateur au niveau des proxy/cache HTTP, donc de n'autoriser que certains employés à accéder au web (par exemple) et d'enregistrer chaque URL demandée avec le login de l'employé demandeur...

[Abogil]

Le modèle OSI date des années 1970...
C'est la base d'un cours réseau, y compris au niveau DUT informatique ou licence générale en Informatique
(je suppose que ton diplôme d'ingénieur n'est pas en informatique)

Et oui, à l'époque le modèle OSI était encore dans les cartons.
Quand j'ai suivi les cours réseaux le modèle OSI ne parlait pas de protocole HTTP . . .

Seul le navigateur web (Internet Explorer) incrusté au logiciel AOL9 passe par les proxy/cache.

Un abonné AOL (qui n'est pas soumis au contrôle parental, une fonction fournie par les serveurs proxy/cache) a la possibilité de lancer un navigateur web indépendant (Internet Explorer, Firefox, Opera...): il ne passe alors plus par les proxy/cache AOL mais arrive "en direct" sur un site web, comme depuis n'importe quel FAI.

Merci Spamplemousse, j'ai enfin les explications claires pour le cache d'AOL.

Cependant en analysant sur mes sites les logs, je m'apperçois que :

• Orange (Wanadoo), Free, Neuf, Cegetel, etc. ont toujours des adresses IP fixe durant toute une session.
• AOL a souvent des adresses IP variables durant toute une session.
• AOL a souvent des adresses IP fixes durant toute une session.

Il me semble pourtant que Orange (Wanadoo), Free, Neuf, Cegetel, etc. offrent l'option du contrôle parental. Option qui est très souvent pris par les abonnés d'Orange. Ce contrôle parental n'empêche pas ces FAI de fournir une adresse IP fixe durant toute la session.

Ces 4 FAI couvrent près de 80 % des accès des visiteurs de mes sites. Comment font ces FAI pour gérer efficacement le contrôle parental et leur immense trafic ? Alors là je ne comprends plus très bien.

[Spamplemousse]

Donc je ne vois pas du tout l'utilité du cache avec changement d'adresse IP à chaque page

Le modèle OSI date des années 1970...
C'est la base d'un cours réseau, y compris au niveau DUT informatique ou licence générale en Informatique
(je suppose que ton diplôme d'ingénieur n'est pas en informatique)

Notions d'architecture
Etude détaillée des protocoles de liaison, notion de correction d'erreur. Introduction à la notion d'architecture en couches. Le modèle TCP/IP, les architectures OSI. Exemples simplifiés de mise en oeuvre.

Les abonnés AOL ne changent pas d'adresse IP, mais ils utilisent une grappe de proxy/cache HTTP qui travaillent en parallèle, exactement comme une grande entreprise qui utilise plusieurs proxy/cache HTTP en même temps pour ses employés.

C'est expliqué sur http://webmaster.aol.fr/sessions.html

Seul le navigateur web (Internet Explorer) incrusté au logiciel AOL9 passe par les proxy/cache.

Un abonné AOL (qui n'est pas soumis au contrôle parental, une fonction fournie par les serveurs proxy/cache) a la possibilité de lancer un navigateur web indépendant (Internet Explorer, Firefox, Opera...): il ne passe alors plus par les proxy/cache AOL mais arrive "en direct" sur un site web, comme depuis n'importe quel FAI.

Mais les employés d'une entreprise qui n'offre pas un accès Internet direct n'ont pas une telle solution à leur disposition...

PS: si ta question est "pourquoi AOL ou une grosse entreprise a-t-elle plusieurs proxy/cache HTTP au lieu d'un seul avec une seule adresse IP ?"
la réponse est triviale: parce que ça ne suffit pas à tenir la charge...
on parle de 300.000 utilisateurs simultanés sur les proxy/cache HTTP par exemple dans le cas d'AOL en France.

Une PME n'aura pas besoin de plusieurs serveurs proxy/cache, donc ça explique pourquoi le problème ne se manifeste qu'avec des entreprises de quelques milliers d'employés au moins...

[Abogil]

Un grand merci Spamplemousse pour ce magnifique cours.

Je suis désolé, mais quand j'ai passé mon diplome d'Ingénieur, les couches OSI n'étaient pas encore à la mode (ou peut-être n'étaient-elles pas encores définies). Donc j'ai quelques lacunes. Encore que . . .

Personnellement j'utilise bien les cookies.

Seulement les abonnés AOL qui utilisent :

• Le navigateur AOL, se retrouvent avec une adresse IP qui change quasiment avec chaque page lue,
• Directement le navigateur IE ou Firefox, se retrouvent avec une adresse IP permanente qui peut durer plusieurs heures,

Donc je ne vois pas du tout l'utilité du cache avec changement d'adresse IP à chaque page puisque tout en étant sur le même réseau AOL et à la même adresse téléphonique, selon que l'on passe par le navigateur AOL ou directement par le navigateur IE ou Firefox on a une adresse IP variable ou fixe.

Par contre, je n'ai pas du tout compris ce que voulait signifier la phrase :

c'est le même problème d'inculture informatique et de dialogue de sourds que lorsqu'on tente d'expliquer la compatibilité Mozilla Firefox aux développeurs qui ne connaissent qu'Internet Explorer]

Pourrais-tu m'éclairer ?

[Spamplemousse]

J'avais déjà trouvé l'explication ici : http://209.85.135.104/search?q=cache...&ct=clnk&cd=14
et je m'étais renseigné sur les NewsGroup quant à la possibilité qu'il y avait de faire çà sur un serveur mutualisé, mais personne n'avait su me répondre.

Exact, l'URL que tu indiques explique concrètement comment configurer le serveur d'applications d'OSCommerce pour faire en sorte que les sessions ne dépendent pas de l'adresse IP du client HTTP.

D'après la documentation PHP disponible sur http://fr2.php.net/session

Passing the Session ID
There are two methods to propagate a session id:

• Cookies
• URL parameter

The session module supports both methods. Cookies are optimal, but because they are not always available, we also provide an alternative way. The second method embeds the session id directly into URLs.

PHP ne semble proposer que les méthodes n°2 et 3 décrites sur http://webmaster.aol.fr/sessions.html pour maintenir l'état de session:

1/ l'adresse IP émettrice d'où provient la requête HTTP sur le serveur
2/ un cookie stocké sur la machine émettrice
3/ la réécriture de l'URL du site, pour y intégrer un identifiant de la session client

D'ailleurs, un utilisateur semble bien confirmer que PHP n'utilise pas l'adresse IP du client HTTP:

http://fr2.php.net/manual/en/ref.session.php#48330

The session support does not use the IP address for validation. It is based on cookies and URL rewriting.

The reason you lose your session when closing your browser and reconnecting to your ISP (so you are changing your IP), is that sessions are only valides for the visit on your web site, not more.

Changing your IP address will not affect your session except if you close your browser.

La gestion des sessions PHP me semble donc totalement compatible avec les proxy/cache HTTP (comme ceux d'AOL ou de diverses entreprises) et il n'y a apparemment rien à faire de particulier, ni au niveau de PHP, ni de ton site web, pour le rendre "compatible"
[tant que tu ne vas pas manipuler toi-même dans ton code PHP (ou dans les librairies PHP que tu utilises) l'adresse IP source de la requête web pour faire des choses "obscènes" et sources d'incompatibilités ]

C'est bien la raison qui me fait penser qu'il pourrait y avoir un "load balancer" chez OVH (comme expliqué dans la note technique AOL) devant les hébergements mutualisés, et que c'est là que se trouve le problème... mais il faudrait que quelqu'un d'OVH connaissant l'architecture technique précise de leurs hébergements mutualisés nous en dise plus...

Combien OVH a-t-il de clients en hébergement mutualisé sur "90plan" ?
Certainement plus de 100 ou de 500, donc de toute façon tous ces clients ne doivent pas "tenir" sur une seule machine... il y a donc probablement plusieurs machines qui se "cachent" derrière l'adresse IP 90plan.ovh.net = 213.186.33.2 et donc des raisons de s'intéresser à la façon dont la répartition de charge s'effectue entre ces différentes machines...

[teopath]

Je suppose qu'OVH n'a pas qu'un seul serveur web hébergeant TOUS les sites sur un "90plan" par exemple.

90plan.ovh.net pointe vers une seule adresse IP: 213.186.33.2

C'est très probablement une adresse IP virtuelle avec derrière une batterie de machines, donc il y a probablement un répartiteur de charge sur cette adresse IP virtuelle: si c'est le cas, il est probable que le problème est dans la configuration de ce répartiteur de charge OVH, et il faut s'assurer (comme indiqué dans la note technique) que la répartition de charge ne se fait pas en fonction de l'adresse IP du client web, ce qui causerait les pertes de sessions sur serveurs mutualisés dont vous parlez -- même si leur moteur PHP est correctement configuré pour faire dépendre les sessions des cookies HTTP (et pas de l'adresse IP qui se connecte).

[Je passe sur le côté complètement ridicule du "je suis hors la loi", quand on connaît le modèle OSI et le protocole HTTP/1.1 et qu'on s'aperçoit que le fonctionnement de ces proxys est absolument conforme aux normes -- c'est le même problème d'inculture informatique et de dialogue de sourds que lorsqu'on tente d'expliquer la compatibilité Mozilla Firefox aux développeurs qui ne connaissent qu'Internet Explorer]

Tout celà est très intéressant (jai tout lu), je n'ai pas tout compris, dans la vie je ne suis qu'un petit ostéopathe, et je revendique sans conteste mon appartenance aux 95% cités plus haut.

J'avais déjà trouvé l'explication ici : http://209.85.135.104/search?q=cache...&ct=clnk&cd=14
et je m'étais renseigné sur les NewsGroup quant à la possibilité qu'il y avait de faire çà sur un serveur mutualisé, mais personne n'avait su me répondre.

Là je sens que j'ai trouvé quelqu'un qui touche alors je repose ma question :

Y a t'il quelquechose à faire à mon niveau pour passer dans ce mode ou le moteur PHP repère les sessions par cookie plutôt que par adresse IP (.htacces ou je ne sais quoi d'autre) ou est ce au niveau d'OVH que çà se passe ?

[Spamplemousse]

C'est du foutage de gueule de la part d'AOL.

AOL est le seul hébergeur ADSL qui utilise ce système de gestion et qui dise aux hébergeurs de site Internet : Je suis hors la loi, débrouillez vous tout seul.

Pas vraiment, c'est plutôt du "foutage de gueule" (selon ton expression) de ta part, et j'espère que tu n'as pas de diplôme en informatique de l'enseignement supérieur français vu ton niveau de connaissances en réseau...

1) faire dépendre l'état de session HTTP (couche 5 du modèle OSI, applicative et au-delà) de l'adresse IP source de la connexion (couche 3 du modèle OSI, réseau) est une violation du principe fondamental d'indépendance des couches du modèle OSI.

C'est la raison pour laquelle faire dépendre la session HTTP d'un cookie ou d'un session-ID intégré à l'URL est de toute façon une méthode préférable car plus conforme à la théorie.

La "théorie" indique donc que faire dépendre la session web de l'adresse IP du client n'est pas une bonne idée, et donc ne devrait pas fonctionner "à tous les coups"... la pratique confirme la théorie, pour une fois.


2) ce problème n'est pas spécifique à AOL --
on le retrouve avec toute (grande) entreprise qui n'offre à ses employés qu'un accès à Internet via une batterie de serveurs proxy/cache HTTP.
D'ailleurs on avait quelqu'un qui évoquait précisément ce problème lorsqu'il se connectait depuis les proxys de son entreprise sur ce forum.

http://www.webmaster-hub.com/index.p...dpost&p=168473

j'ai un script qui me permet de controler les sessions des utilisateurs qui visitent mes sites. Je me base sur un certain nombe de paramètres pour valider que la session est bien celle de l'utilisateur. Un de ces paramètres est l'adresse IP du client. Si cette adresse IP change pour une même session, je considère qu'il y a tentative de vol de session et je réinitialise la session.

Mon problème est le suivant: quand on se trouve derrière un proxy pour se connecter au net (le cas en général dans une entreprise), ce proxy peut utiliser du laod balancing avec plusieurs IP (donc plusieurs machine) pour se connecter au net. Du coup l'adresse IP du client peut changer... Mon système d'identification réinitialise alors les sessions... Donc pas top, on est connecté dans la zone privée et 30s plus tard on se fait jeter.

3) le protocole HTTP, dès son invention il y a environ 15 ans, a prévu la possibilité et l'emploi de proxy/cache HTTP qui servent d'intermédiaires entre les utilisateurs finaux et les serveurs web.

Leur protocole et leur comportement est complètement prévu et normalisé (en particulier dans la norme HTTP/1.1) et il n'y a absolument rien dans le fonctionnement d'une grappe de serveurs proxy en parallèle (telle qu'AOL ou certaines entreprises la mettent en oeuvre) qui constitue une violation de la norme HTTP/1.1.

Il n'y a donc absolument rien qui soit "hors la loi", contrairement à ce que tu avances.
(merci de m'indiquer le paragraphe de la norme HTTP/1.1 qu'AOL violerait, selon toi... histoire qu'on rigole)

Bref, le vrai problème est toujours le même...

Des développeurs web à l'horizon limité à une seule plateforme et une seule architecture qui développent une application, qui fonctionne pour 90% ou 95% des cas, et qui tentent de rejeter le blâme (dû à leur manque d'expérience) sur les 5% qui restent...

Pourquoi s'emm**der à développer des applications portables puisque 98% des gens utilisent Windows ?
On n'a qu'à indiquer aux 2% restants de changer de système d'exploitation...

Pourquoi s'emm**der à développer des applications compatibles Firefox/Safari/Opera respectant les standards du web puisque 90% ou 95% des gens utilisent Internet Explorer ?
Il n'y a qu'à utiliser mod_rewrite, comme suggéré par Yggdrasil,
pour rediriger automatiquement depuis son site web tout autre navigateur web sur www.microsoft.com/ie

Pourquoi s'emm**der à développer des applications respectant la norme HTTP/1.1 puisque 95% des gens utilisent une architecture triviale, avec le navigateur web (client HTTP) qui se connecte directement à mon serveur HTTP ?
Tant pis pour les 5% restants qui passent par un proxy/cache HTTP/1.1 intermédiaire, ils n'ont qu'à changer de FAI ou d'entreprise après tout...


Le plus risible dans cette histoire est qu'il n'y a rien à développer pour être compatible avec des clients web qui se connectent via des proxy/cache HTTP intermédiaires...

Il suffit, comme indiqué dans la note technique AOL, de configurer son serveur d'applications (PHP ici) pour qu'il n'utilise pas l'adresse IP du client web, mais plutôt les cookies.

C'est juste une préférence du moteur PHP (ou de n'importe quel autre serveur d'applications), et il suffit de le savoir pour la positionner, une fois pour toutes, à la bonne valeur. Ca suffit pour rendre compatible (avec AOL ou des proxys d'entreprise) les sites web hébergés sur des serveurs dédiés par exemple.

Par contre, comme l'indique la note technique, il faut s'assurer qu'il n'y a pas en amont des serveurs web un "load balancer" qui ferait du partage de charge d'après l'adresse IP du client...

Je suppose qu'OVH n'a pas qu'un seul serveur web hébergeant TOUS les sites sur un "90plan" par exemple.

90plan.ovh.net pointe vers une seule adresse IP: 213.186.33.2

C'est très probablement une adresse IP virtuelle avec derrière une batterie de machines, donc il y a probablement un répartiteur de charge sur cette adresse IP virtuelle: si c'est le cas, il est probable que le problème est dans la configuration de ce répartiteur de charge OVH, et il faut s'assurer (comme indiqué dans la note technique) que la répartition de charge ne se fait pas en fonction de l'adresse IP du client web, ce qui causerait les pertes de sessions sur serveurs mutualisés dont vous parlez -- même si leur moteur PHP est correctement configuré pour faire dépendre les sessions des cookies HTTP (et pas de l'adresse IP qui se connecte).

[Je passe sur le côté complètement ridicule du "je suis hors la loi", quand on connaît le modèle OSI et le protocole HTTP/1.1 et qu'on s'aperçoit que le fonctionnement de ces proxys est absolument conforme aux normes -- c'est le même problème d'inculture informatique et de dialogue de sourds que lorsqu'on tente d'expliquer la compatibilité Mozilla Firefox aux développeurs qui ne connaissent qu'Internet Explorer]

[Abogil]

Au final je vais gérer le problème en mettant ce lien sur l'entrée du site.

Celui qui n'est pas content n'a qu'à changer de FAI

[teopath]

http://webmaster.aol.fr/sessions.html

Au final je vais gérer le problème en mettant ce lien sur l'entrée du site.

Celui qui n'est pas content n'a qu'à changer de FAI

[Abogil]

... et je n'ai plus aucuns problèmes avec ces gens là ... pas plus qu'avec GWA ...

Google et AOL mettent les webmasters devant le fait accompli ... c'est inadmissible

Mais les abonnés d' AOL ne peuvent visiter ton site.

[Yggdrasil]

Extrait de http://webmaster.aol.fr/sessions.html :

C'est du foutage de gueule de la part d'AOL.

AOL est le seul hébergeur ADSL qui utilise ce système de gestion et qui dise aux hébergeurs de site Internet : Je suis hors la loi, débrouillez vous tout seul.

Au risque de paraître excessif, cela fait belle lurette que j'ai ajouté les lignes suivantes à mon htaccess :

order allow,deny
Deny from aol.com
Deny from ^(72.14.192.|72.14.194.)
allow from all

... et je n'ai plus aucuns problèmes avec ces gens là ... pas plus qu'avec GWA ...

Google et AOL mettent les webmasters devant le fait accompli ... c'est inadmissible

[Abogil]

http://webmaster.aol.fr/sessions.html

Extrait de http://webmaster.aol.fr/sessions.html :

Résolution :

Ne pas utiliser l'adresse IP source des requêtes Web pour maintenir un état de session ou faire du partage de charge.
La méthode de remplacement la plus simple à déployer est de se baser sur les cookies HTTP. La réécriture des URL fonctionne parfaitement mais peut avoir d'autres effets non souhaitables, notamment en cas de partage d'URL entre deux utilisateurs ou de mise en marque-page.

C'est du foutage de gueule de la part d'AOL.

AOL est le seul hébergeur ADSL qui utilise ce système de gestion et qui dise aux hébergeurs de site Internet : Je suis hors la loi, débrouillez vous tout seul.

[Spamplemousse]

http://webmaster.aol.fr/sessions.html

[teopath]

Hé bien ça consiste simplement à créer des scripts PHP, donc de la doc pas vraiment à part la doc de PHP. Le but c'est de créer quelque chose qui permette de stocker des données temporairement pour chaque visiteur, tu utilises ce qui te semble le plus simple ou le plus performant, une bdd, des fichiers etc. Pour le mutualisé il n'y a pas de soucis, c'est de la programmation PHP classique de toute façon, après peut-être qu'il y a des scripts tout faits sur le net, faudrait jeter un oeil.

Oui, çà il n'y a pas de problème, je sais faire.

Le problème c'est que le session permet d'identifier de façon certaine le visiteur de la page par son adresse IP et ce sans trop se fatiguer.

Actuellement les visteurs d'AOL arrivent à s'enregistrer dans ma BDD mais pas à aller plus loin.

Je n''en n'ai pas encore eu d simultanément (fatalement puisque le site ne fonctionne pas pour eux), mais ils ont tous été enregistré avec la même adresse IP.

Pour toute les variables servant à passer les données "bateau", elles existent déjà dans la BDD, donc j'irai lire la base plutôt que de les passer par la session et la variable d'identification sera cryptée et passée par l'URL

Merci pour les infos, bonne journée à tous.

[Noxiweb]

Hé bien ça consiste simplement à créer des scripts PHP, donc de la doc pas vraiment à part la doc de PHP. Le but c'est de créer quelque chose qui permette de stocker des données temporairement pour chaque visiteur, tu utilises ce qui te semble le plus simple ou le plus performant, une bdd, des fichiers etc. Pour le mutualisé il n'y a pas de soucis, c'est de la programmation PHP classique de toute façon, après peut-être qu'il y a des scripts tout faits sur le net, faudrait jeter un oeil.

[teopath]

Non il y a bien un soucis avec AOL et son système de proxy clusterisé couplé à son navigateur et ce depuis de nombreuses années. A l'époque où je prenais encore le temps de me pencher sur les soucis qu'à AOL avec un peu tout, ça ne se produisait que quand la personne passé par le navigateur AOL mais pas quand il passait par IE par exemple. Sinon pour en savoir plus il y a de quoi lire par ici. La seule vraie solution à tout ça reste, comme j'ai dit, de créer son propre système de sessions, certains sites l'ont fait comme par exemple Prizee qui me vient à l'esprit.

Désolé, suis encore un peu néophyte, j'ai pris un hébergement chez ovh car j'en avais marre des possibilités limitées de chez wanamoo.

C'est quoi "son propre système de sessions" ?

Ou je pourrais trouver de la doc làdessus ?

C'est possible de gérer çà sur un hébergement mutualisé ?

[teopath]

Les sessions php marchent très bien avec AOL, il ne faut juste pas faire de vérifications ou se baser sur l'ip car la leur changer quasiment à chaque page qu'ils visitent.

Je crois que justement le serveur se base sur l'IP pour gérer les sessions et c'est ce qui fout la merde.

[Noxiweb]

Non il y a bien un soucis avec AOL et son système de proxy clusterisé couplé à son navigateur et ce depuis de nombreuses années. A l'époque où je prenais encore le temps de me pencher sur les soucis qu'à AOL avec un peu tout, ça ne se produisait que quand la personne passé par le navigateur AOL mais pas quand il passait par IE par exemple. Sinon pour en savoir plus il y a de quoi lire par ici. La seule vraie solution à tout ça reste, comme j'ai dit, de créer son propre système de sessions, certains sites l'ont fait comme par exemple Prizee qui me vient à l'esprit.

[Shadow aok]

Les sessions php marchent très bien avec AOL, il ne faut juste pas faire de vérifications ou se baser sur l'ip car la leur changer quasiment à chaque page qu'ils visitent.

[Noxiweb]

Bonsoir,

Oui AOL est dans ce système depuis plusieurs années sans que ça l'inquiète, la solution est de créer ton propre système de sessions.

[teopath]

Bonsoir à tous

J'ai créé un site ou le visiteur s'identifie par mot de passe puis dont l'identification est vérifié par chaque page grace à une variable transmise par une session php.

Jusque là, tout va bien.

Malheureusement il y a AOL qui semble (selon ce que j'ai lu sur le net) utiliser un proxy qui redéfinit un peu aléatoirement les adresses IP.

Résultat : Aol et cession php çà ne fait pas bon ménage.

Quelqu'un cconnait il une astuce pour tourner le problème ?

J'ai un 90 plan

D'avance merci