2009-07-29 6 views

Répondre

11

Ne dépendez jamais des informations provenant du client. Dans ce cas, vous vous heurtez à des problèmes de réseau simples (vous ne pouvez jamais être sûr que l'adresse IP du client est correcte), dans d'autres cas, le client peut usurper des informations à dessein.

Si vous avez besoin d'identifier vos clients de manière unique, leur remettre un cookie lors de leur première visite, c'est ce que vous pouvez faire de mieux.

0

Je ne pense pas qu'il existe d'autres moyens faire ce que tu veux. En effet, le serveur proxy transfère les requêtes des clients et agit en leur nom. Ainsi, les clients sont virtuellement cachés du point de vue du serveur. Cependant, je peux me tromper.

0

Si vous connaissez le serveur proxy, je pense que cela implique qu'il s'agit d'une sorte de réseau local d'entreprise. Êtes-vous en contrôle du LAN? Construire et installer un plugin ActiveX qui envoie un identifiant unique au serveur peut être la solution.

En général, les serveurs proxy HTTP sont et non requis pour envoyer l'adresse IP de leur client. Ainsi, chaque requête envoyée par un proxy semble provenir de l'adresse IP du proxy. (Bien que le wikipédia mentionne des en-têtes personnalisés, certains proxies envoient pour transmettre le client's ip.)

Cela devient encore pire quand un proxy HTTP utilise lui-même un autre proxy HTTP - le serveur recevant la requête obtiendra seulement l'adresse IP du serveur. dernier proxy dans la chaîne, et il n'y a aucune garantie que le deuxième proxy est même au courant que le 1er proxy n'était pas un client régulier!

5

Votre meilleur pari serait:

$uid = md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['REMOTE_ADDR']); 

cependant, il n'y a aucun moyen de savoir s'ils ont changé leur agent utilisateur ou un autre navigateur.

+2

Si deux personnes derrière le même proxy utilisent le même navigateur, cela ne fonctionne pas. – deceze

+0

Exactement, il n'y a aucun moyen d'être sûr à 100% de qui il s'agit, vous pouvez utiliser des combos de différentes $ _SERVER vars et prier pour qu'ils soient uniques d'une manière ou d'une autre. – OneOfOne

4

Vous pouvez utiliser d'autres en-têtes pour aider, comme ceux-ci (ceux qui viennent à l'esprit quand on regarde une décharge de $_SERVER):

  • HTTP_USER_AGENT
  • HTTP_ACCEPT
  • HTTP_ACCEPT_LANGUAGE
  • HTTP_ACCEPT_ENCODING
  • HTTP_ACCEPT_CHARSET

En utilisant plusieurs informations provenant du client contribuera Différencier différents clients (plus d'informations que vous utilisez, plus les chances que vous avez au moins un d'entre eux est différent entre deux clients) ...

... mais ce ne sera pas une solution parfaite :-(

en fonction du type de logiciel proxy et sa configuration, il pourrait y avoir un en-tête appelé X-Forwarded-For, que vous pouvez utiliser:

le X-Forwarded- Pour l'en-tête HTTP (XFF) est un de fa cto standard pour identifier l'adresse IP d'origine d'un client se connectant à un serveur Web via un proxy HTTP ou un équilibreur de charge. C'est un en-tête de demande non standard RFC qui a été introduit par les développeurs du serveur proxy de mise en cache de Squid.

Mais je ne reposerait pas sur ce soit: il sera probablement pas toujours présent (ne pense pas que son nécessaire)

Bonne chance!

+0

X-Forwarded-For peut être utile pour cette situation exacte. Vous ne pouvez pas compter dessus, surtout pour l'unicité, mais c'est utile. – zombat

+0

Je ne suggère pas de combiner une adresse IP avec 'USER_AGENT' pour identifier les gens. Les navigateurs comme la mise à jour automatique de Chrome, qui change la chaîne tout le temps. Certaines chaînes de navigateur reflètent également les plugins installés qui peuvent changer. Même si vous venez d'extraire le nom du navigateur, vous n'êtes jamais vraiment sûr qu'il n'a pas été falsifié. – Robbert

0

JKS,

Les machines distantes n'ont pas d'identifiants uniques. C'est impossible.

Habituellement, les développeurs aiment suivre les machines lorsque l'utilisateur final visite une page avec un formulaire comme un login pour des raisons de sécurité.

Voici ce que je fais: Je stocke un cookie, une variable de session et utilise le nouveau html5 localStorage pour suivre les gens sur mes pages sensibles. C'est vraiment le seul moyen de le faire avec précision. La bonne chose à propos de localStorage (lorsque les navigateurs peuvent le faire), l'utilisateur final n'a généralement aucune idée que vous stockez des choses sur leur machine et la suppression des cookies n'a aucun effet.

Vous pourriez faire une table de base de données avec des détails de suivi comme: horodatage , ip_address, user_agent

alors disons que vous suivez les tentatives de connexion infructueuses .. Je ferais ceci:

if(isset($_SESSION['failed_logins'])) { 
     $failed_logins = $_SESSION['failed_logins']; 
     $_SESSION['failed_logins'] = ($failed_logins + 1); 
} else { 
     $_SESSION['failed_logins'] = 1; 
} 

I ferait alors la même chose avec setcookie(), puis le script localStorage ..

Maintenant, je suis suivi de cette personne et de savoir combien de fois ils échouent un login ..

J'écrirais alors les données de cet utilisateur dans ma table failed_login comme décrit ci-dessus. Je suis sûr que ce n'est pas la réponse que vous cherchiez, mais c'est vraiment la meilleure façon de suivre les utilisateurs sur votre site.

+1

Veuillez ne pas stocker le nombre d'échecs de tentatives de connexion dans une variable de session. À la fin, '$ _SESSION' est juste un autre cookie suivi par Apache. L'utilisateur n'a qu'à supprimer le cookie contenant l'identifiant de session pour réinitialiser ses tentatives de connexion échouées. Au lieu de cela, une bonne solution consisterait à enregistrer un horodatage des trois dernières tentatives de connexion échouées pour chaque utilisateur de votre base de données. Si tous les trois ont eu lieu dans les 5 minutes qui suivent 'now()', n'autorisez pas les tentatives de connexion. – Robbert

Questions connexes