Comment vérifier que quelqu'un possède un site Web?

10

J'essaie de trouver des moyens de vérifier, de la manière la plus sûre possible, qu'un utilisateur possède un site Web qu'il prétend posséder.

Voici quelques façons que j'ai vues:

  • Téléchargez un fichier HTML au nom obscur dans le répertoire racine avec un contenu donné
  • Inclure une balise META ou un autre commentaire quelque part dans la source de la page d'accueil
  • Envoyer un e-mail à une adresse @domainwearetryingtovalidate.tldavec un lien de vérification
  • Vérifier un enregistrement CNAME ou TXT
  • Vérifier les enregistrements WHOIS
  • Valider physiquement en appelant ou en envoyant un e-mail à la ligne d'assistance, en mettant à jour manuellement les enregistrements

Et voici les problèmes avec ces méthodes, dans l'ordre:

  • Certaines configurations de sites Web peuvent ne pas permettre de simplement télécharger un fichier à la racine
  • Une mauvaise conception du site peut permettre à un utilisateur de ce site d'ajouter lui-même cette balise META
  • Les sites Web qui fournissent des services de messagerie électronique rendent cela inutile; prenez gmail.compar exemple
  • C'est trop complexe pour la plupart des petits propriétaires de sites Web pour savoir comment faire
  • Ce sont publics; n'importe qui peut prétendre être qui que ce soit. Sans oublier le plus souvent inexact.
  • Huuuuge perte de temps

Existe-t-il d'autres moyens de vérifier qu'un utilisateur de votre site possède un site Web particulier? Parmi les méthodes que j'ai énumérées, lesquelles sont les meilleures et les pires? Je les ai commandés du meilleur au pire à mon avis, mais j'aimerais aussi voir ce que les autres pensent.

Je prévois d'implémenter un ou plusieurs d'entre eux en PHP.

php  ownership 
— Cyclone
source
3
C'est très certainement une question de programmation. Si cela devait être sur des webmasters, je le mettrais là.
Pour une solution automatisée, vous êtes fidèle à ce que vous avez listé. D'autres grandes sociétés (par exemple Google) utilisent l'une des quatre premières options. Je trouverais cela incroyablement irrégulier pour un utilisateur de ne pas pouvoir faire l'un des quatre premiers.
1
@ rlb.usa Ce serait une question pour les webmasters si je demandais comment ajouter un enregistrement CNAME à mon domaine pour vérifier que je le possédais pour un service particulier
2
Je pense que le premier problème que vous devez résoudre est de décider: que signifie "posséder" un site Web? Être administrateur? Vous avez accès au système de fichiers? Vous avez un droit de propriété légal? Vous avez une obligation d'entretien par voie d'accord écrit ou parlé? Payer les factures d'hébergement? Payer les factures de domaine? Payer les designers?
— Courses de légèreté en orbite
1
@Cyclone: Je suis travaille pour vous gratuitement, en vertu du fait que je gaspille mon temps complètement contribuer à cette question.
— Courses de légèreté en orbite

Réponses:

9

Je pense vraiment

  • Téléchargez un fichier html au nom obscur dans le répertoire racine avec le contenu donné

est la meilleure façon de procéder. J'ai dû faire ça une fois. Et je ne pense pas que de nombreuses configurations de sites Web vous empêchent de le faire.

Si cela vous inquiète vraiment, pourquoi ne pas autoriser toutes les options (sûres)?

Concernant votre commentaire:

Oui, mais avec les systèmes MVC (tels que codeigniter), il peut être difficile de comprendre comment accéder à un fichier physique qui ne fait pas partie du système principal

Dans ces rares cas, laissez ces administrateurs utiliser les enregistrements CNAME / TXT ou appelez-les :-)

— aioobe
source
1
Bon ... c'est en fait là que je devais le faire ;-)
2
Les deux premiers que j'ai répertoriés provenaient des outils Google pour les webmasters
@Cyclone, je suis d'accord avec vous que le premier semble plus sécurisé que le second.
La chose qui craint à ce sujet est que vous vous retrouvez avec un fichier au nom obscur par service, encombrant le répertoire racine. Ce n'est pas une faille terrible, mais il existe des alternatives plus propres.
— Bobby Jack
Hmm .. Je pense que vous y avez temporairement mis le nom obscur pendant le processus de vérification.
— aioobe
7

Le téléchargement d'un fichier au nom obscur est la voie à suivre.

Vous avez écrit que l'inconvénient est qu'ils ne peuvent pas être autorisés à télécharger un fichier à la racine. Eh bien, dans ce cas, cela signifie qu'ils ne possèdent pas le site Web, ce que vous essayez de découvrir.

— laurent
source
Exactement. Vous n'avez pas besoin d'un accès "root" au serveur, c'est-à-dire en dehors du dossier htmlou www.
— Chris Laplante
Je ne veux pas dire que les règles de réécriture peuvent rendre le téléchargement du fichier difficile ou complexe
@Cyclone, c'est vrai mais je suppose qu'il est assez rare de refuser l'accès à un fichier HTML physique.
Oui, mais avec les systèmes MVC (tels que codeigniter), il peut être difficile de comprendre comment accéder à un fichier physique qui ne fait pas partie du système principal
Je pense que CI autorise toujours l'accès aux fichiers HTML physiques. Mais juste au cas où, vous pourriez également autoriser la méthode de métabalise, afin que vos utilisateurs ne soient pas bloqués en cas de problème avec leur fichier .htaccess ou leur framework MVC.
1

Je recommanderais d'utiliser la balise META ...

  • Inclure une balise META
0

Personnellement, j'irais avec l'option de messagerie automatisée.

Demandez à l'utilisateur de saisir son URL et son adresse e-mail, en vérifiant que le domaine est le même dans les deux cas. Ils utilisent le même système que les systèmes de réinitialisation de mot de passe:

  • Générer un hachage aléatoire, composé en partie du microtime et du domaine actuels
  • Stocker le hachage dans une base de données
  • Envoyez à l'utilisateur un e-mail avec un lien de vérification, où le paramètre «id» est le hachage
  • Maintenant, l'utilisateur est vérifié (supprimez la ligne de la base de données)

Pour plus de sécurité, stockez l'heure à laquelle le hachage a été généré, puis faites-le expirer après une heure ou deux.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.