Comment détecter si le navigateur client accepte les cookies ?

[ortolojf]

Bonsoir

J'ai pensé... gérer le fait de mémoriser un contenu spécifique au cours de la navigation d'un navigateur sur un site, en le transmettant dans des fichiers, dont les noms soient dérivés de l'identificateur de session, donné par la fonction php session_id()

Cependant... Il va de soi, que je ne pourrais récupérer le contenu d'un fichier comme celà, qu'à partir du moment où je sais son nom, donc l'identificateur de session, ce qui suppose que celui-ci ne change pas quand un visiteur passe d'une page à une autre.

Mais... Pour que celà soit possible, il faut, soit que le navigateur client accepte les cookies, soit que l'identificateur de session, soit transmis classiquement en get dans l'url ( de la forme : PHPSESSID=...etc...

Le problème, est d'une part que j'ai des urls rewritées, et d'autre part que je ne souhaite pas qu'il y ait des identificateurs de session dans les urls ( même urls rewritées ), pour des raisons de référencement.

Celà m'amène donc, au point de départ: Pouvoir vérifier automatiquement et rapidement, si le navigateur client accepte les cookies, ce qui fait qu'il ne sera plus nécessaire d'utiliser des fichiers, puisque les cookies suffiront pour transmettre les données souhaitées, pendant la naviagation d'un visiteur.

Donc, voici ma question : Comment, d'une manière fiable, savoir si un navigateur client accepte les cookies, de préférence en php, sachant que s'il n'accepte pas les cookies, il sera très difficile de savoir pendant l'exécution d'une page ( = d'un script php ), si c'est la page initiale, ou la deuxième page exécutée ?

Si je savais que les cookies ne sont pas acceptés par le navigateur client, je pourrais demander au visiteur, d'accepter les cookies, sachant que celà sera nécessaire, pour s'abonner et/ou s'authentifier, et accéder aux pronostics.

D'autre part, j'ai besoin que cette vérification ne soit pas faite en Javascript, car précisément j'ai besoin que les cookies soient activés, pour pouvoir vérifier que Javascript l'est aussi. ( c'est un détail ).

Ce problème de cookie, est relatif à la programmation en cours du site http://www.lespronostics.com , dont je suis en train de mettre au point les scripts d'abonnement ( téléphone surtaxé et Carte Bleue ) et d'authentfication des abonnés.

Merci beaucoup de votre réponse à ma question.

Bien à vous.

Amicalement.

Jean-François Ortolo

 

[ortolojf]

Rebonsoir

Bon, je me répond à moi-même, après avoir consulté Google et un site de forum de programmation asp/php :

Il suffit de tester si la constante SID , est vide ou non, après avoir activé la session avec session _start();.

Si SID est vide, c'est que le navigateur accepte les cookies. Dans le cas contraire, il n'accepte pas les cookies, et SID contient l'affectation du cookie de session, de la forme ( le plus souvent ) : PHPSESSID=<value>

Seulement, il y a un bug... C'est que celà n'est valable, que si la page a été rechargée au moins une fois.

Si le script contenant l'activation de la session puis le test de SID, n'est affiché qu'une seule fois, SID est non vide dans tous les cas. ;(

Cependant,... Dans mon cas, celà ne devrait pas poser de problème, car le script de test d'acceptation ou non de cookie, sera nécessairement différent de la première page accédée, du site par le visiteur.

J'ai donc simplement besoin, de déclencher une session dans toutes les pages, puis de tester SID au moment du test.

Problème résolu.

Bien à vous.

Amicalement.

Jean-François Ortolo

 

[Zecat]

tu peux aussi au choix :

1 - poser un cookie et le relire pour voir

ou

2 - si ton site a analytics, tu lis le cookie utma de google ...

 

[Zecat]

tu peux aussi au choix :

1 - poser un cookie et le relire pour voir

ou

2 - si ton site a analytics, tu lis le cookie utma de google ...

 

[ortolojf]

tu peux aussi au choix :

1 - poser un cookie et le relire pour voir

ou

2 - si ton site a analytics, tu lis le cookie utma de google ...

Bonsoir Zecat

Je sais bien, mais... :

Je ne peux pas savoir, quand un script s'exécute, si je suis sur la première page, ou la deuxième.

Le procédé que j'envisage, est facile à implémenter sur le site :

Je déclenche une session sur toutes les pages du site, avec session_start().

Et puis, dans la page ( == le script php ) où je fais le test, je teste si SID est vide.

Facile...

Merci beaucoup de ta réponse.

Amicalement.

Jean-François Ortolo

 

[Leonick]

si ton site a analytics, tu lis le cookie utma de google ...

sauf que ce cookie n'existera qu'à partir de la 2° page lue

 

[Zecat]

si ton site a analytics, tu lis le cookie utma de google ...

sauf que ce cookie n'existera qu'à partir de la 2° page lue

et si le gars n est jamais venu sur le site :wink:

 

[ortolojf]

J'ai mis au point dans mon esprit...

...Un procédé pour vérifier à la fois si Javascript est accepté, et/ou si les cookies sont acceptés.

Un script php reçoit un paramètre choix en GET, qui peut être à la valeur 1 ( première exécution ), ou 2 ( deuxième exécution ).

Si choix==1, le script démarre la session ( session_start(); ) , puis alimente la variable de session js, avec le nombre de secondes depuis le 1er Janvier 1970 : $_SESSION['js'] = time(); , puis fait un exit; sans rien afficher, après avoir fait un session_write_close(); pour bien faire.

Si choix == 2, le script démarre la session, puis évalue la valeur de la constante SID.

Si SID est vide ( empty(SID) === true), le script affiche "OK#", sinon il affiche "BAD#", puis il fait un session write_close(); pour faire bonne mesure, puis rend la main avec un exit;

Donc, dans la page html, il y a un script Javascript, qui lance sucessivement, de manière synchrone, dans les règles de l'art, ce script php, successivement avec le paramètre choix=1 puis choix=2 en GET, avec en plus un paramètre dummy=new Date.getTime(); , pour que le script soit réellement lancé dans tous les cas ( En effet sinon, il y aurait simplement un appel au cache, et le script ne serait pas lancé aux chargements suivants de la page html ).

Après le premier lancement, il ne se passe rien, mais la variable de session js a été alimentée.

Après le deuxième lancement, la variable Javascript responseText est évaluée, elle est tronquée juste avant le dièze terminal, puis sa valeur est évaluée.

Si le résultat est égal à "OK", pas de fenêtre modale, tout s'est bien passé, les cookies sont acceptés par navigateur client.

Si le résultat est égal à "BAD", une fenêtre modale Javascript s'affiche, indiquant qu'il faut configurer le navigateur, pour accepter les cookies.

--------------

Bien entendu, ce traitement n'est possible qu'en Javascript, sinon la variable de session js n'est pas alimentée, ou sa valeur est inférieure de plus de 300 secondes ( == 5 minutes ), à celle de la fonction php time();

Le script php produisant la page html prend en compte celà, et affiche ses éléments en fonction.

Par exemple, il peut afficher un message indiquant qu'il faut activer le Javascript sur le navigateur client, et afficher son formulaire ( accessible uniquement en Javascript ), en mode "disabled", pour que le visiteur soit obligé d'activer Javascript, pour l'utiliser.

Le seul bug, est que ce message ( et le mode "disabled" ), seront affichés par défaut lors du premier chargement de la page html du site, même si Javascript est activé. En effet, le script php générant la page html, s'effectue avant le script Javascript qu'elle contient.

Je pourrais, dans le script Javascript, déclencher un reload de la page html, d'une manière ou d'une autre ( Il y a différentes instructions possibles suivant la version de Javascript ), mais je ne sais pas comment détecter le premier chargement de la page html, de façon à ne faire un reload de la page, qu'au moment du premier chargement de la page html. Autrement, il y aurait des rechargements infinis de la page html.

Pourriez-vous m'indiquer, un moyen de détecter le fait que la page html est chargée pour la première fois ?

Celà me permettrait de soulager le visiteur, de devoir recharger la page manuellement.

J'ai envisagé de tester l'existence d'un fichier dont le nom dépendrait du client. Mais là, le problème est encore de disposer d'une valeur caractéristique de la connexion client, donc équivalente à un identificateur de session. Et si les cookies sont refusés... ;(

Comment faire ?

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo

 

[Leonick]

le sid, il faut laisser le serveur le gérer, car là, en utilisant uniquement les secondes, tu vas avoir des doublons avec des visiteurs arrivant au même moment.
une solution, que Zecat devrait apprécier :wink:, serait de poserles cookies et de faire recharger la page. Tu enregistres en parallèle l'ip du visiteur dans un fichier et lors de l'arrivée d'un visiteur sans cookie, tu vérifies si l'ip se trouve enregistrée dans ton fichier il y a moins de 2-3 secondes (laisser un petit temps de latence pour que le navigateur ait le temps de charger et recharger). A voir, pour améliorer avec de l'ajax

 

[ortolojf]

Bonjour Leonick

En fait, j'ai trouvé théoriquement, comment détecter si la page a été chargée pour la première fois.

Lors du premier lancement du script ( choix == 1 ), celui-ci alimente la variable de session $_SESSION['js'] , puis teste l'existence du fichier session_ . session_id() . ".txt"

S'il n'existe pas, il le remplit avec la valeur du session_id(); ( ou avec n'importe quoi ), et affiche la chaîne "REP#", qui indique au script Javascript, qu'il faut recharger la page( window.location.reload(true); ).

Lors du deuxème lancement du script, tout de suite après, il y a les instructions : $sid=SID; , et :

if(empty($sid))
echo"OK#";
else
echo "BAD#";

Si le script rend : "BAD", dans le script Javascript, une fenêtre modale est déclenchée, indiquant qu'il faut accepter les cookies.

J'ai placé un script de test, à l'url : http://www.lespronostics.com/squelettes/tmp_js.html

Cà marche.

Vous pouvez tester, avec Javascript désactivé ( rien ne se passe ), pui sactivé et les cookies refusés ( la fenêtre modale s'affiche ), ou accepté ( elle ne s'affiche pas ).

L'étape suivante, est de tester en php, si la variable $_SESSION['js'] est valide ( existe et date de moins de 5 minutes ).

Je ferai celà ce soir.

Comme la page a nécéssairement été rechargée si Javascript est activé, cette variable est valide, si et seulement si Javascript est activé.

Il est donc possible de faire un traitement automatique, en fonction de si Javascript est activé ou non.

D'autre part, le visiteur n'a plus besoin de recharger sa page, manuellement.

Problème résolu.

Bien à toi.

Amicalement.

Jean-François Ortolo

 

[Leonick]

L'étape suivante, est de tester en php, si la variable $_SESSION['js'] est valide ( existe et date de moins de 5 minutes ).

comme dit au dessus, il faut laisser le serveur gérer lui-même les sessions. Si tu veux une durée de 5', tu règle ça au niveau des paramètres du serveur

 

[Leonick]

par contre, pourquoi utiliser ajax ? le fait qu'en js on ne trouve pas de cookie (qui devraient y être vu que la page a été chargée) devrait suffire pour afficher l'alerte ?

 

[ortolojf]

L'étape suivante, est de tester en php, si la variable $_SESSION['js'] est valide ( existe et date de moins de 5 minutes ).

comme dit au dessus, il faut laisser le serveur gérer lui-même les sessions. Si tu veux une durée de 5', tu règle ça au niveau des paramètres du serveur

Bonjour Leonick

Il y a une différence entre : variable de session non existante ( ou expirée ), et variable de session datant de plus de 5 minutes.

De toute manière, ça ne mange pas de pain d'affecter la valeur time() à cette variable de session. De plus, cette affectation est faite théoriquement, à chaque chargement de page...

Amicalement.

Jean-François Ortolo

 

[ortolojf]

par contre, pourquoi utiliser ajax ? le fait qu'en js on ne trouve pas de cookie (qui devraient y être vu que la page a été chargée) devrait suffire pour afficher l'alerte ?

Bonjour Leonick

J'ai besoin de tester si Javascript est activé ou non. Donc j'utilise Ajax, qui, s'il fonctionne, m'indique que Javascript est activé.

La variable de session $_SESSION['js'] , si elle existe et est valide, indique que Javascript est activé, autrement j'affiche le formulaire d'abonnement Carte Bleue, en mode "disabled", de manière à ce que le visiteur ne puisse pas l'utiliser. Avec un message demandant au visiteur d'activer le Javascript.

En effet, ce formulaire fonctionne avec une fonction Javascript ( plusieurs fonctions Javascript ) associée, et ne fonctionnerait pas du tout si Javascript n'était pas activé.

D'autre part, je préfère que les cookies soit acceptés, pour pouvoir authentifier un visiteur connecté, pour lui permettre l'accès aux pronostics, s'il s'est identifié avec le formulaire.

L'intermédiaire de paiement est Allopass, et j'ai été obligé de faire de véritables acrobaties pour m'arranger de son interface de formulaires, d'abonnement ou d'accès. Pour les abonnements Carte Bleue, ces formulaires fonctionnenet avec Javascript. C'est comme ça. ;(

Cependant, Allopass a un avantage, c'est qu'ils payent réglo, contrairement à l'intermédaire de paiement qu'avait mon site partenaire, avant d'être migré vers Allopass. Je ne dis pas lequel...

Je vais faire le dernier test ce soir pour tmp_js.html , puis commencer à assembler le script php qui générera la page html où figureront les formulaires, et les scripts Javascript.

Bien à toi.

Amicalement.

Jean-François Ortolo

 

[Leonick]

la page me semble bien
Par contre, qu'est ce que ça fait au niveau du visiteur si le délai de 5' est dépassé ? a-t-il encore besoin de sa variable de session ?
si tu affectes la valeur de time(), tu risques de te retrouver avec plusieurs personnes qui auront la même variable de session, et donc qui pourraient avoir accès aux pages payantes, mais sans payer et sans avoir tenté de passer outre ta protection.
Le mieux serait de mettre l'heure d'arrivée, si tu en as besoin, dans la variable de session, mais le sid resterait calculé par le serveur. Si tu veux absolument le créer toi même, fais plutôt un md5 de l'heure d'arrivée, de l'ip de connexion et du UA, en ajoutant une autre valeur permettant d'éviter qu'un internaute ne se crée lui-même son propre sid

 

[ortolojf]

la page me semble bien
Par contre, qu'est ce que ça fait au niveau du visiteur si le délai de 5' est dépassé ? a-t-il encore besoin de sa variable de session ?
si tu affectes la valeur de time(), tu risques de te retrouver avec plusieurs personnes qui auront la même variable de session, et donc qui pourraient avoir accès aux pages payantes, mais sans payer et sans avoir tenté de passer outre ta protection.
Le mieux serait de mettre l'heure d'arrivée, si tu en as besoin, dans la variable de session, mais le sid resterait calculé par le serveur. Si tu veux absolument le créer toi même, fais plutôt un md5 de l'heure d'arrivée, de l'ip de connexion et du UA, en ajoutant une autre valeur permettant d'éviter qu'un internaute ne se crée lui-même son propre sid

Mais non...

Si le délai de 5 minutes est dépassé, il y a une possibilité pour que Javascript ait été activé, puis désactivé.

C'est un détail, et comme je suis maniaque comme un Analyste-Programmeur qui cherche à tenir compte de tous les détails...

La variable de session $_SESSION['js'] , ne me sert pas pour authentifier les visiteurs connectés, mais simplement pour détecter si Javascript est activé ou non.

D'autre part, comme c'est une variable de session, elle est particulière à chaque visiteur, évidemment.

Enfin, j'ai constaté, à mon grand effroi, que quand les cookies sont refusés par le navigateur client, la fonction session_id() change de valeur au fur et à mesure des chargements successifs d'une même page, à partir du même navigateur, même session.

Celà fait, que je ne peux pas faire de rechargement automatique ( par window.location.reload(true); ) de la page, car je n'ai quand les cookies sont refusés, aucun moyen de savoir si c'est le premier chargement de la page, ou non.

Je me suis donc résigné,à ne pas faire de rechargement automatique.

Je pense que le visiteur, quand il verra le message d'activer Javascript ou de recharger la page, aura pour première réaction, si Javascript est activé, de le savoir, et de recharger la page manuellement, ce qui fera prendre en compte par le script php générant la page html, la variable de session $_SESSION['js'] , donc le fait que Javascript est activé.

A cause de ces différents identificateurs de session, ( cookies refusés ), j'ai eu une série de rechargements répétitifs et rapides, et le répertoire de fichiers "sessions_" . session_id() . ".txt" qui se remplissait dangereusement... ;(

Je gère le fait que ce répertoire se remplisse de toute manière, en affectant deux répertoires, l'un pour un nombre de jours pair depuis le 1er Janvier 1970, l'autre pour un nombre de jours impair.

Dans le script php qui génère la page html, je testerai si le répertoire d'hier, contient encore le fichier repère indiquant que le répertoire contient encore des fichiers, et dans ce cas, le script effacera tous les fichiers de ce répertoire.

Cela me permettra de ne pas accumuler les fichiers à perte de vue.

Donc, problème résolu à peu près, mai seulement à peu près.

Cependant, j'ai constaté, que la fenêtre modale indiquant qu'il faut accepter les cookies, a tendance à ne s'afficher qu'incomplètement, sans être remplie, comme s'il y avait un problème réseau. Bizarre...

Merci beaucoup de ta réponse.

Amicalement.

Jean-François Ortolo

 

[Leonick]

Enfin, j'ai constaté, à mon grand effroi, que quand les cookies sont refusés par le navigateur client, la fonction session_id() change de valeur au fur et à mesure des chargements successifs d'une même page, à partir du même navigateur, même session.
A cause de ces différents identificateurs de session, ( cookies refusés ), j'ai eu une série de rechargements répétitifs et rapides, et le répertoire de fichiers "sessions_" . session_id() . ".txt" qui se remplissait dangereusement... ;(

d'où l'idée que je te donnais d'utiliser un fichier pour conserver les dernières ip connectées et de supprimer ensuite ces ip du fichier s'il y a bien la présence de cookie.

 

[ortolojf]

d'où l'idée que je te donnais d'utiliser un fichier pour conserver les dernières ip connectées et de supprimer ensuite ces ip du fichier s'il y a bien la présence de cookie.

Bonsoir Leonick

Effectivement, un fichier contenant les adresses ip connectées de provenance, serait un bon moyen de tester si la page et accédée pour la première fois...

Sauf pour les visiteurs qui ont aol come fournisseur d'accès Internet... ;(

Je peux théoriquement tester si c'est le cas, et ne pas faire de rechargement dans ce cas, mais s'il y a d'autres fournisseurs d'accès Internet qui changent d'adresse ip tout le temps, j'aurai le même problème de répertoire qui se remplit dangereusement...

Je peux très bien utiliser l'adresse ip remote, pour nommer le fichier témoin indiquant si la page est accédée pour la première fois, simplement en changeant le code du script php lancé par Ajax par le script Javascript. Facile.

Merci beaucoup de ta suggestion, je vais examiner celà demain soir.

Le problème en fait, est de savoir si aol est le seul fai qui change d'adresse ip tout le temps.

Amicalement.

Jean-François Ortolo

 

[Leonick]

sur un délais de 4-5 secondes, tu as quand même de grandes chances que l'ip n'ai pas été modifiée. En plus, ça ne concernerait que les visiteurs qui n'ont pas les cookies d'activés et à partir de la 2° page, si cookies activés tu supprimes l'ip dans le fichier

 

[ortolojf]

sur un délais de 4-5 secondes, tu as quand même de grandes chances que l'ip n'ai pas été modifiée. En plus, ça ne concernerait que les visiteurs qui n'ont pas les cookies d'activés et à partir de la 2° page, si cookies activés tu supprimes l'ip dans le fichier

Bonjour Leonick

C'est vrai que l'adresse ip ne risque pas de changer en une fraction de seconde, encore que...

De toute manière, comme les noms de fichiers, dépendront de ces adresses ip, et que de toute façon, les adresses ip sont en nombre relativement limité pour les fai dont les adresses ip changent en cours de route, il n'y aura pas un remplissage trop fort du répertoire des fichiers.

De toute manière, les abonnés à ce type de fai, ne pourront pas consulter les pronostics ( s'authentifier ), car si l'adresse ip change en cours de route, la variable de session d'authentification, ne sera plus valable. ( C'est une variable différente de $_SESSION['js'] ).

Compte tenu de cette limitation, qui concerne pratiquement tous les types d'authentification client pour les sites web, je ne pense pas que cette pratique de changer d'adresse ip, puisse être répandue si peu que ce soit ( à part aol évidemment ).

Je vais donc faire la modification que tu suggères.

Merci beaucoup pour tes avis.

Amicalement.

Jean-François Ortolo

 

[Leonick]

De toute manière, les abonnés à ce type de fai, ne pourront pas consulter les pronostics ( s'authentifier ), car si l'adresse ip change en cours de route, la variable de session d'authentification, ne sera plus valable. ( C'est une variable différente de $_SESSION['js'] ).

pourquoi ? pour éviter l'usurpation de session ? le "prêt" ou vol de cookie ? une solution consisterait à forger un cookie avec le début de l'adresse ip ainsi que le user agent, car même si l'ip change chez de rares fai, elle reste toujours dans le même range ip, donc si tu prends les 3 premiers blocs, ça ne devrait pas changer.

 

[ortolojf]

Bonjour Leonick

Voilà, les modifications sont faites.

Cà marche.

Les fichiers ont pour noms : "session_from_" . gethostbyaddr($_SERVER['REMOTE_ADDR']) . ".txt"

Il sont situés dans le répertoire : $repert = "./sessions" . (floor(time() / ( 24 * 60 * 60 )) % 2 . "/";

Celà donne deux répertoires possibles : sessions0 et sessions1 alternativement, changés quotidiennement à minuit.

J'incoporerai dans le script php générant la page, le code de nettoyage du répertoire inutilisé ( celui d'hier ), c'est-à-dire détection de si le fichier sessions.tmp existe dans ce répertoire, et dans ce cas, ouverture du répertoire et effacement de tous ses fichiers, de manière automatique.

J'ai testé le fait que le bon fichier de session correspondant à mon adresse ip, était inscrit dans le bon répertoire, une seule fois, et que le rechargement de la page, ne se faisait qu'un seule fois, et que le PHPSESSID figurait parmi mes cookies dans mon navigateur.

Cependant, la variable de session, qui devrait être un cookie, ne figure pas parmi les cookies de mon navigateur, ce qui m'étonne. Je ne sais pas pourquoi.

Je testerai bientôt dans le code php du script générant la page html, que cette variable de session, a bien été alimentée.

Comme cette variable de session $_SESSION['js'] , n'est valable que si les cookies sont acceptés, je suis simplement obligé de procéder en pensant que les visiteurs vont effectivement accepter les cookies ( suite à l'affichage éventuel de la fenêtre modale en ce sens ).

Je pourrais éventuellement, dans le script alimentant cete variable de session, vérifier qu'elle existe ( dans ce cas les cookies sont acceptés ), et si elle date de plus de 5 minutes, supprimer le fichier de session correspondant ( voir ci-dessus ), ce qui rechargera la page.

Cependant, à la limite, dans ce cas-là ce n'est pas nécessaire de recharger la page, le visiteur s'en chargera en continuant sa visite du site. Je vais donc m'abstenir.

Dans l'ensemble, problème résolu, sous réserves qu'il n'y ait pas un problème de remplissage trop fort du répertoire, associé à des rechargements multiples de la page, dus au fait que le nombre d'adresses ip différentes soit grand, et que ces adresses ip, soient modifiées très rapidement pour le même visiteur.

Celà est très peu probable, mais je ne peux pas tester en réel, n'étant pas abonné à aol ( Dieu, ou ce qui en tient lieu, merci ).

Merci beaucoup beaucoup de ton aide.

Je pense que j'ai résolu un problème classique en webmastering, de la manière peut-être la plus fiable et simple possible, avec le minimum de moyens.

Merci encore.

Amicalement.

Jean-François Ortolo

 

[ortolojf]

pourquoi ? pour éviter l'usurpation de session ? le "prêt" ou vol de cookie ? une solution consisterait à forger un cookie avec le début de l'adresse ip ainsi que le user agent, car même si l'ip change chez de rares fai, elle reste toujours dans le même range ip, donc si tu prends les 3 premiers blocs, ça ne devrait pas changer.

Bonjour Leonick

Pour la variable de session certifiant l'authentification du visiteur, j'utiliserai la méthode ultra basique, en faisant confiance au fait qu'il n'est possible de faire semblant d'être authentifié, qu'en se connectant à partir une adresse ip identique à celle d'un abonné déjà authentifié.

En effet, une variable de session ne dure que le temps que le navigateur fonctionne, donc à partir d'une adresse ip donnée, et n'est pas valable pour toute autre adresse ip de connexion.

C'est le principe des variables de sessions, de dépendre de l'adresse ip, et du fait que les cookies sont activés.

En fait, je n'ai jamais compris, comment on pouvait "voler" une variable de session.

Si tu pouvais m'expliquer...

Bien à toi.

Amicalement.

Jean-François Ortolo

 

[Leonick]

C'est le principe des variables de sessions, de dépendre de l'adresse ip, et du fait que les cookies sont activés.
En fait, je n'ai jamais compris, comment on pouvait "voler" une variable de session.

en fait, c'est le navigateur qui la gère, c'est un cookie comme les autres et il y a beaucoup de moyens de se créer ou modifier les cookies, ne serait-ce qu'avec l'addon web developper toolbar sur FF.
Tu verras, cet outil est indispensable si tu veux faire des vérifications de tes scripts de suivis de cookie, pouvoir les modifier sur ton navigateur, ça t'évite de devoir faire ton test à 23h59'59 pour vérifier que le changement de date ne pose pas de problème, par exemple...

 

[ortolojf]

pourquoi ? pour éviter l'usurpation de session ? le "prêt" ou vol de cookie ? une solution consisterait à forger un cookie avec le début de l'adresse ip ainsi que le user agent, car même si l'ip change chez de rares fai, elle reste toujours dans le même range ip, donc si tu prends les 3 premiers blocs, ça ne devrait pas changer.

Bonjour Leonick

Effectivement, je pourrais...

A supposer que ce soit toujours ipv4, et non pas ipv6.

Mais bon... Les abonnés aol sont habitués à ne pas pouvoir s'authentifier sur les sites web, alors...

Et puis, quand je vois le très faible nombre d'abonnés aol venant sur mon propre site ( gratuit d'ailleurs ), je ne pense pas que le site que je programme pour le directeur de mon site partenaire, ait particulièrement besoin de ces visiteurs. ;(

Celà me paraît délicat, car l'unicité pour les trois premiers blocs associés à l'user agent, ne me paraît pas très fiable.

Il est vrai que je pourrais limiter celà, aux abonnés aol reconnaissable d'après le reverse de leurs adresses ip, mais...

Je vais m'abstenir.

Je reconnais, que ce sera une faille dans ce site. ;(

Merci beaucoup de tes conseils.

Amicalement.

Jean-François Ortolo

 

[ortolojf]

en fait, c'est le navigateur qui la gère, c'est un cookie comme les autres et il y a beaucoup de moyens de se créer ou modifier les cookies, ne serait-ce qu'avec l'addon web developper toolbar sur FF.
Tu verras, cet outil est indispensable si tu veux faire des vérifications de tes scripts de suivis de cookie, pouvoir les modifier sur ton navigateur, ça t'évite de devoir faire ton test à 23h59'59 pour vérifier que le changement de date ne pose pas de problème, par exemple...

Bonjour Leonick

Bon, je vais peut-être faire une sorte de cryptage de valeurs codées de la variable de session d'authentification, en fonction de certains paramètres dépendant de la connexion, et de manière unidirectionnelle genre ( md5($param_connexion) ), pour valider les authentifications au moment de l'accès aux pronostics.

Celà fera, que la valeur de ce cookie d'authentification, sera variable, non seulement en fonction des visiteurs, mais également en fonction du moment du premier accès au site. C'est la condition sine qua non, pour qu'un visiteur ne réutilise pas le cookie généré après une première authentification en tant qu'abonné, ce qui lui permettrait de simuler une authentiifcation ultérieurement, sans se réabonner.

Je vais me pencher sur la question, après avoir mis au point les formulaires d'abonnements et d'accès.

Celà concernera uniquement le module de calcul du cookie d'authentification, et celui de la validation de ce cookie lors des accès aux pronostics.

Merci beaucoup beaucoup de ta suggestion, tu me tire une très grosse épine du pied.

Très affectueusement.

Jean-François Ortolo

 

[Leonick]

Celà me paraît délicat, car l'unicité pour les trois premiers blocs associés à l'user agent, ne me paraît pas très fiable.

non, je ne t'ai pas dit juste là dessus, c'est ces 2 critères, plus le sid. Donc pour pouvoir passer outre la protection par le sid, il faudrait pouvoir récupérer le sid d'une session d'un abonné qui serait sur la même range ip et aurait le même UA, ça restreint quand même pas mal les possibilités.
Il est évident que les range ip + UA seuls ne sont pas suffisants

 

[ortolojf]

non, je ne t'ai pas dit juste là dessus, c'est ces 2 critères, plus le sid. Donc pour pouvoir passer outre la protection par le sid, il faudrait pouvoir récupérer le sid d'une session d'un abonné qui serait sur la même range ip et aurait le même UA, ça restreint quand même pas mal les possibilités.
Il est évident que les range ip + UA seuls ne sont pas suffisants

Bonjour Leonick

Le seul problème, c'est que ce sid n'est valable, que si les cookies sont acceptés. Sinon, il varie pour le même visiteur à chaque chargement de page.

Et encore, le sid, dans ce cas, n'est valable que si l'adresse ip remote ne change pas. Donc bug pou rles abonnés aol.

Or, je ne peux savoir si les cookies sont acceptés, que si Javascript est activé, d'après la manière que j'utilise pour celà.

Effectivement, le sid ( ou encore mieux, le session_id() seul ) serait idéal, associé éventuellement avec les trois premiers blocs de l'adresse ip, et l'user agent.

D'un autre côté, cette variable discriminante, j'en ai besoin aussi pour les accès téléphone surtaxé, qui ne nécessiteront pas nécessairement Javascript, mais ceux qui auront eu un ticket téléphonique ( = un code d'accès après avoir téléphoné au numéro surtaxé ), ne pourront s'authentifier, que si les cookies sont acceptés. ;(

D'autre part, cette variable discriminante, j'en ai besoin aussi, dans le cas des abonnés aol, pour le nom du fichier de session, or ce nom est fixé avant que je sache si les cookies sont acceptés, c'est-à-dire avant que j'ais la possibilité d'afficher la fenêtre modale, demandant d'accepter les cookies.

Si je veux prendre, comme variable discriminante, la valeur de la fonction time() au moment du premier chargement de page du site ( avant que le fichier de session n'existe ), j'ai évidemment besoin d'enregistrer cette variable ( qui sera combinée aux trois premiers blocs de l'adresse ip, et à l'user agent ), dans un endroit où je puisse la retrouver en fonction du client. Et là, bug, le serpent se mord la queue... ;(

Donc, la conclusion ultime, est que j'ai absolument besoin dans tous les cas, que Javascript soit activé, et que les cookies soient acceptés.

De plus, les abonnés aol, comme en définitive je ne peux pas mémoriser et retrouver avec certitude cette variable discriminante si leur adresse ip change, ne pourront de toute façon, pas s'authentifier après s'être abonnés.

Comment les autres sites web réglent le problème des authentifications avec les abonné saol, je ne sais pas.

Sais-tu comment ces sites web fonctionnent, pour authentifier les abonnés aol ?

Merci beaucoup de ta réponse.

Amicalement.

Jean-François Ortolo

 

[Leonick]

si tu laisses le serveur gérer le sid, il ne dépendra pas de l'ip ni rien d'autre en provenance du visiteur. Il est transmis par cookie, donc si les cookies sont acceptés, même si l'ip change, ça ne posera pas de problème.
La seule chose c'est que, si je m'entends avec un autre de tes abonnés, on peut se passer la valeur du sid et pouvoir fonctionner les 2 en même temps avec le même sid, d'où mon idée d'ajouter une variable de session comprenant le range ip et l'UA

 

[ortolojf]

si tu laisses le serveur gérer le sid, il ne dépendra pas de l'ip ni rien d'autre en provenance du visiteur. Il est transmis par cookie, donc si les cookies sont acceptés, même si l'ip change, ça ne posera pas de problème.
La seule chose c'est que, si je m'entends avec un autre de tes abonnés, on peut se passer la valeur du sid et pouvoir fonctionner les 2 en même temps avec le même sid, d'où mon idée d'ajouter une variable de session comprenant le range ip et l'UA

Bonjour Leonick

Donc, problème résolu.

Je teste avec ma méthode si Javascript est activé, et les cookies acceptés.

Le visiteur acepte les cookies ( je l'oblige, ou bien il s'aperçoit après qu'il ne peut pas s'authentifier ).

Donc, le sid est stable.

Donc... Je peux alimenter la variable de session d'authentification, avec une combinaison de session_id(), des trois premiers blocs de l'adresse ip, et de l'user-agent.

Celà suppose seulement, que les cookies sont acceptés, ce qui suppose, dans mon cas, que Javscript soit activé, pour que je puisse afficher la fenêtre modale demandant d'accepter les cookies.

Et... comme je n'ai besoin du fichier de session ( = dont le nom est le reverse de l'adresse ip ), qu'un court moment, l'adresse ip ne change pas entre le premier affiichage de la page, et son rechargement ( ou bien ne change pas au rechergement suivant ), donc ma méthode de test de Javascript activé et d'acceptation des cookies est fiable.

Comme le sid ne change pas, les variables de session restent accessibles, même si l'adresse ip change ?

Oui oui ?

Merci beaucoup de ta réponse.

Jean-François Ortolo

 

[ortolojf]

Bonsoir Leonick

C'est dommage, j'ai du supprimer l'User Agent comme composante de la variable de session d'authentification.

En effet, celle-ci est alimentée par des scripts php lancés en Ajax, l'User Agent n'est donc pas disponible pour le calcul de la variable.

Je concatène l'identificateur de session ( session_id() ) , et l'adresse ip tronquée de son dernier nombre, et du point qui le précède. Je calcule ensuite le md5() de la valeur obtenue. J'espère que ça marche aussi en ipv6... ;(

Ce n'est pas aussi sécurisé que ce que tu préconise, mais je n'ai pas d'autre solution, car l'User Agent d'une requête Ajax, est entièrement différent de celui du navigateur.

Le script de test est à l'url : http://www.lespronostics.com/squelettes/formulaires.php

Tu peux tester dans toutes les configurations possibles : Javascript activé ou non, cookies permis ou non, etc...

Merci beaucoup de tes conseils.

Amicalement.

Jean-François Ortolo

 

[ortolojf]

Bonsoir

Je suis très fier d'avoir disposé sur le site http://www.lespronostics.com que je suis en train de programmer pour le directeur de mon site partenaire, les formulaires d'abonnement à droite sur chacune des pages.

Les pronostics ne sont pas encore filtrés. De toute façon, ce n'est pas la peine de s'abonner ou de chercher à obtenir un ticket téléphonique.

Les abonnements Carte Bleue ne fonctionnent pas pour l'instant. L'utilisateur reçoit un mot de passe, mais il ne peut pas se connecter avec, car l'inscription n'est pas répercutée sur la base de données du site.

Celà vient du fait, que Allopass se trompe d'url quand il la lance en réponse aux abonnements. Cette url est bien configurée dans le compte Allopass de mon directeur, mais il semble que Allopass ait un problème actuellement, pour en tenir compte. Il lance une url qui semble être une url par défaut, comme si aucune url n'était configurée.

Par contre, les tickets téléphoniques semblent fonctionner.

J'insiste sur le fait, qu'il ne faut pas s'abonner actuellement ni acheter de ticket téléphonique, car les pronostics sont visibles sans s'abonner pour l'instant.

Il semble, que le fichier graphique pour les tickets téléphoniques, soit peu visible. Merci de me dire ce que vous en pensez. J'ai été obligé de réduire la taille en fonction de la largeur disponible à droite pour les formulaires.

Je suis très fier de l'interface que j'ai mise au point pour inciter le visiteur à activer Javascript, et accepter les cookies.

C'est un problème récurrent en webmastering, que j'ai résolu d'une manière fiable et compatible, je crois, avec la plupart des navigateurs.

Vous pouvez vous contenter de tester les affichages sans vous abonner, avec Javascript activé ou non, et en acceptant ou refusant les cookies.

Merci beaucoup de vos suggestions.

Pensez-vous, que celà vaudrait la peine, que je permettre le référencement de ce site dès maintenant ?

Actuellement, il y a un fichier robots.txt qui interdit aux robots des moteurs de recherche, d'indexer le site.

L'apparence graphique n'est pas mise au point, les contenus sont approximativement fixés.

Bien à vous.

Amicalement.

Jean-François Ortolo