Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage PHP sessions, sessions

sessions, sessions

28 réponses
Avatar
Lascap
Ben c'est le sujet du mois, on dirais...
bref, je suis confronté au problème suivant: il se trouve que les sessions
php ne me satisfont pas tout à fait
à vrai dire, il semblerait que dans certains cas, avec certaines configs de
client, les sessions ne fonctionnent pas (notamment si le type refuse tous
les cookies, mais ce n'est pas tout à fait le seul cas, visiblement.) et
comme je n'ai pas trouvé de config du php.ini avec session_use_cookies = 0
qui fonctionne (à part en utilisant le session_trans_id qui ne me satisfait
pas), j'ai décidé de développer mon propre module de session.
du coup, en 2 mots comment je procède:

1. je génère un id que je veux etre le plus caractéristique possible: a
priori c'est un mix entre le HTTP_USER_AGENT et l'adresse ip
2. a partir de cet id, je génére sur mon serveur un fichier, dont le nom
correspond (aux caratères interdits pres).
3. au début de chaque script, grace à l'appel de _sessionLascap_start(), je
(re)génére l'id, regarde si le fichier existe, et si c'est le cas, charge
les variables
4. a la fin de chaque script, je "sérialise" les variables et les écrits
dans un fichier qui porte le nom généré.

le tout fonctionne très bien, MAIS

j'imagine plus que je me trouve confronté le problème suivant:

si 2 types, avec exactement le même HTTP_USER_AGENT (le même OS + le même
navigateur, quoi), utilisent le même proxy et regardent le même site en
même temps, ça va poser un gros problème.

je me demande donc s'il est possible de récupérer une information typique
d'un poste que je pourrais concatener à mon id pour un faire quelque chose
de vraiment unique. (genre si je pouvais récupérer le nom du poste, style,
ça serait génial.)
mais voilà, est-ce possible?????

ps/ pour ceux que ça intéresse, les sources d'un script de test et de la
lib.

http://www.olasia.org/tests/testSession2.php

Lascap
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
John Gallet
Super.. ca fait juste un peu rebelz de désactiver les cookies,


Merci d'aller continuer ce troll sur fr.comp.infosystemes.www.auteurs où le
sempiternel sujet du biscuit or not biscuit sera j'en suis certain acceuilli
avec tous les honneurs qui se doivent.

fu2.
JG

Avatar
John Gallet
là je t'arrete tout de suite, il est hors de question que je passe l'id de
session une seule fois en get, post ou autre



Et tu le passes comment alors entre le client et le serveur ? Par pigeon
voyageur ?

pour que le gars devine que l'id est généré à coup d'ip, de user_agent
voire

de résolution ou autre, faut qu'il soit fort, ou alors qu'il suive de près
les post de fr.comp.lang.php


Halte aux conneries ! Dès qu'on voit 32 chars on sait que c'est un md5. Et
pour le reste, tous les blaireaux qui n'ont rien compris au routage IP et
qui ne lisent pas les FAQ utilisent $REMOTE_ADDR.

Un identifiant de session doit nécessairement êter ALEATOIRE. C'est pourtant
pas compliqué, il suffit d'utiliser correctement la fonction rand() et ses
petites copines.

JG

Avatar
marc guillaume
Gg wrote:

Te spammer? Un cookie ne contient rien d'autre que ce que le site a bien
voulu mettre, le cookie ne va pas contenir des infos sur toi à moins que
tu les donnes au site, et même dans ce cas là, quelle belle jambe, le
cookie est utilisé par ce site.


Ah ? parce que tu crois que les cookies genre double-clic qui arrivent avec
une jolie image sont destinés au site que tu visites ? Une fois que tu as
ce genre de cookie tu es en base de donnéeS. Dans un premier temps tu n'es
que le cookie numéro machin. On ne sait rien d'autre que le fait que ce
numéro de cookie est actif sur une machine. Et à chaque fois que tu passes
sur un site qui a le petit cookie en question on essaye de grappiller un
http-referer ou autre info. Au minimum on sait par quels sites tu passes.
Avec le temps on dégage ton "profil" d'internaute. Puis un jour par
malchance tu passes une commande de quelque chose à un site un peu proche
du poseur de cookie (qui appartient par exemple à la même société, ce que
tu ne sais pas). Là du coup il devient possible d'associer avec ce numéro
de cookie anonyme suivi depuis des mois tout ce que tu viens de saisir :
ton nom, ton adresse, adresse mail etc.

Là cela devient beaucoup moins sympathique et innocent, on sait que monsieur
machin, et non plus un cookie anonyme, va voir tel type de site (politique,
de warez, de sexe, de commerce, d'information ou que sais-je), qu'il achète
en ligne. On peut commencer à vendre son adresse dans des mailings
ciblés...

Tu penses peut-être que c'est de la parano ? Libre à toi. Mais à ton avis,
leur truc à la mode le "data mining", il se base sur quoi ?

Je suis d'acccord avec toi que si l'on veut vivre absolument caché on n'a
pas d'ordinateur et encore moins de connexion à internet. Mais entre cela
et se retrouver fiché toutes les cinq minutes il y a un milieu. C'est tout
ce que je voulais dire.

Il serait d'ailleurs de bon ton sur les sites employant les cookies qu'une
page explique leur nombre et leur utilité afin que l'internaute puisse se
faire une idée sur l'opportunité ou pas d'accepter ou refuser et essayer de
contrôler si ce qu'on lui envoit correspond à ce qui est annoncé. Cela
arrive mais c'est très rare, alors que c'est recommandé par la cnil.

Avatar
Lascap
"John Gallet" a écrit dans le message de news:
3f5b1b98$0$27604$
$_SERVER["REMOTE_ADDR"]);



Non. Lisez la FAQ de forum.
http://faqfclphp.free.fr/



bien vu. Mais du coup

"Dans le cas où il y a un (au moins) proxy, les variables
$HTTP_X_COMING_FROM et $HTTP_VIA sont positionnées. " est intéressant pour
moi. Des commentaires là dessus??? $HTTP_X_COMING_FROM est l'adresse de la
machine, et $HTTP_VIA celle du proxy, c'est ça??


Avatar
Matthieu Aubry
Halte aux conneries ! Dès qu'on voit 32 chars on sait que c'est un md5. Et
pour le reste, tous les blaireaux qui n'ont rien compris au routage IP et
qui ne lisent pas les FAQ utilisent $REMOTE_ADDR.



Bon je suis peut etre un de ces blaireaux là, mais en tout cas j'ai un
énorme problème qui rend mon appli non opérationnelle dans certains cas
(application de stats).
Voici ma fonction d'extraction de l'IP :

function get_ip()
{
if (getenv("HTTP_CLIENT_IP"))
{
$ip = getenv("HTTP_CLIENT_IP");
}
elseif(getenv("HTTP_X_FORWARDED_FOR"))
{
$ip = getenv("HTTP_X_FORWARDED_FOR");
}
else
{
$ip = getenv("REMOTE_ADDR");
}
return $ip;
}

Elle n'est donc pas optimale ?
Si non, devais je utiliser la fonction de Marc Meurrens pour être certain
d'obtenir un identifiant unique ? (on ne peut plus parler d'ip lorsque l'on
concatène plusieurs vars ?)

En tout cas, pourquoi certains personnes ont une IP différente à chaque page
vue différente ? J'ai souvent ce probleme avec les personnes dont le host
est de la forme cache.XXXXXX.proxy.aol.com
Qu'est ce qui explique ce changement d'IP tout le temps ?

Merci d'avance d'éclaircir mon esprit, et par la même occasion d'enrichir
mon appli en la rendant plus fiable.
Cordialement
Matthieu Aubry

Avatar
Lascap

Et tu le passes comment alors entre le client et le serveur ? Par pigeon
voyageur ?



je ne vais pas me répéter 15 fois, non plus...

pour que le gars devine que l'id est généré à coup d'ip, de user_agent
voire

de résolution ou autre, faut qu'il soit fort, ou alors qu'il suive de
près


les post de fr.comp.lang.php

Halte aux conneries ! Dès qu'on voit 32 chars on sait que c'est un md5.


ben oui, encore faut t'il savoir ce qui est codé en md5. Parce que bon,
savoir que c'est du md5, ou n'importe quel autre algo de cryptage, ça fait
généralement pas avancer de beaucoup le schmilblik


pour le reste, tous les blaireaux qui n'ont rien compris au routage IP et
qui ne lisent pas les FAQ utilisent $REMOTE_ADDR.


ouais, ben d'ailleurs, une ptite question aux rois des réseaux : J'ai donc
regardé les fonctions de Marc Meurrens concernant l'obtention d'un id - ip
unique, et j'y ai aussi trouvé une faille: les types qui sont derrière une
"fausse passerelle", qui est en fait une machine sous linux redirigeant les
paquets internet <-> lan par des simples règles iptable ne permette de
définir aucune des variables dont il parle: ni http_via, ni
http_[X-]forwarded[-for], rien (enfin si, remore_addr, quoi....) dans ces
conditions, il semble que son script n'a pas l'effet souhaité, et c'est bien
dommage (parce qu'avec des "vrais" proxy, ça marche bien).

Lascap


Avatar
bertrand
Je me demande aussi si la solution ne viendrais pas de l'exploitation des
connections persistentes définies dans HTTP 1.1 ?
...
Maintenant reste à définir avec précision ce qu'est une connexion
persistante... Entre ce que j'imagine (et ce que ça devrait être, on est en
2003 quand même) et ce que c'est réellement...

Quelqu'un de mieux informer peut surement nous en dire plus...


Bonsoir,

A ma connaissance, ce n'est pas la solution.
Une connexion persistante, c'est une connexion entre le client et le
serveur qui est maintenu pendant un certain nombre de requète/réponse
dans le but de récupèrer rapidement tous les éléments de la page requètée.
Cette connexion n'est établie qu'au niveau réseau. Le serveur web, ne
voit pas la différence entre les 8 requètes d'une connexion persistante
et les 75 autres qui lui arrivent dans le même laps de temps.
Il n'y a pas de connexion donc de contexte en HTTP.

Les cookies sont la seule bonne solution existante au problème de la
création d'un contexte à ce niveau. (le passage de sess_id dans l'url
est pire que tout pour la sécurité)

Les cookies sont par ailleurs aussi un problème de sécurité du fait de
recoupements qu'ils permettent entre site. (dans le cas d'intention
malveillante). La solution de ce problème passe par des navigateurs
capable de paramètrage fins entre cookie à ne conserver que durant la
session, cookie à garder plus longtemps pour tel ou tel site...

La sécurité passe aussi par un nettoyage régulier dans les cookies
conservés!

Cordialement

--
Bertrand Perrotte

Webmaistre canoe.kayak.free.fr
secrétaire du Canoë Kayak Gennevilliers

Avatar
kMoog
Les gens désactivent tout aussi facilement le Java et le Javascript que les
cookies
:o(((

Il y a une solution paliative :
- Quand c'est un utilisateur non authentifié, tu te contentes de ta solution
car il n'y a vraiment pas le choix.
- En revanche, quand l'utilsateur se logge, tu génère un petit Id ( de 0 à
99999) et tu l'ajoutes dans le md5 pour obtenir un Id unique.

Tu utilises alors 2 fichiers :
- simplement le nom de l'utilisateur pour stocker le fichier de variables et
tu prends soin de stocker l'Id unique dans le fichier.
- un fichier dont le nom est l'Id unique et qui contient pour seule variable
le nom de l'utilsateur.


Il te suffit alors de passer le petit id par url.
A chaque fois qu'une page s'ouvre, si le petit Id est présent :
- Tu recrée l'Id unique.
- Tu ouvre le fichier nommé avec l'Id unique pour récupérer le nom de
l'utilisateur.
- Tu contrôle si l'Id unique stocké dans le fichier utilisateur est bien le
même que celui que tu a recréé.
Si ce n'est pas le cas, il y a tentative d'usurpation.

A chaque déconnection/Reconnection, tu recrée le même processus car, bien
evidemment, il ne faut pas que le petit Id soit attribué définitivement à un
utilisateur.
L'idéal est aussi de faire un système de délog qui, s'il est utilisé, efface
le fichier nommé avec l'Id unique et efface l'Id unique dans le fichier
utilisateur.

Le seul hic, c'est sur un seul et même ordinateur partagé :
- Si Mr A s'est loggué, qu'il a navigué sur ton site, il a laissé des traces
dans l'historique du navigateur.
- Si Mr A s'est délogué avant de fermer son navigateur, la sécurité est
excellente.

- Mais si Mr A ne s'est pas délogué et Si Mr B arrive derrière lui et qu'il
utilise un lien de l'historique, il sera authentifié par ton site comme Mr A
:o(((
- Le même problème se pose si quelqu'un du réseau de l'entreprise est
malveillant et qu'il s'ammuse à pirater les liens visités par les
utilisateurs et qu'il utilise les liens de MrA (toujours dans le cas ou Mr A
ne s'est pas délogué).

Sinon, pour une sécurité absolue, tu peux faire un système qui change le
petit Id à chaque changement d'url.
Dans ce cas, même un administrateur malveillant ne pourra pas pirater la
"Session" de Mr A.

Mais dans ce cas, l'utilisateur (Notre Mr A, en l'occurence) ne peut plus
utiliser les boutons Page Precedente/Page suivante de son navigateur puisque
le petit Id des anciennes pages ne sera plus valide.

Voili voilou...

"Zouplaz" a écrit dans le message de news:

Lascap - :


si 2 types, avec exactement le même HTTP_USER_AGENT (le même OS + le
même navigateur, quoi), utilisent le même proxy et regardent le même
site en même temps, ça va poser un gros problème.

je me demande donc s'il est possible de récupérer une information
typique d'un poste que je pourrais concatener à mon id pour un faire
quelque chose de vraiment unique. (genre si je pouvais récupérer le
nom du poste, style, ça serait génial.)
mais voilà, est-ce possible?????



Et la situation risque de se poser... Dans une entreprise où les postes
utilisent le même OS, le même navigateur et passe par un routeur ou
firewall et donc la même adresse IP...

Mais ton idée est très bonne, reste à trouver un moyen de générer un ID
qui soit propre à chaque poste. Et là y a peut-être un moyen, allez
délirons un peu ;-)

voici la séquence :
1) monscript.php est appellé une première fois
2) $_GET['UID'] existe ?
3) oui on continue l'exécution du script et on récupère les variables
stockées lors du dernier appel, s'il y en a
4) non on redirige vers genUID.php?url=monscript.php
5) genUID.php génère une page htm contenant une applet java, on passe à
l'applet java le nom du script (en l'occurence ici monscript.php)
6) lors de l'exécution de l'applet java on récupère un maximum d'infos
sur le poste (IP, résolution d'écran, "os.arch", "os.name", "os.version",
"user.name", etc) et calcule un ID numérique
7) a la fin de l'exécution de l'applet, on redirige vers le script passé
en paramètre auquel on ajouté UID= avec la valeur de l'ID

et retour en 1)

Bon... ahem... Amusant...
Qu'est ce qu'on a de plus qu'avant qui peut aider à la génération d'un id
unique (enfin, un peu moins générique disons) ? la résolution d'écran,
peut-être le nom de l'utilisateur (et encore je connais rien à java
alors)..

Par contre comme l'applet s'exécute côté client il y a peu être d'autres
renseignements disponibles qui pourraient permettre de générer un ID
beaucoup plus spécifique (voire totalement spécifique ???) au poste
client...



Allez, je retourne bosser au lieu de délirer...



1 2 3