web-dev-qa-db-ja.com

Webサイトにアクセスするコンピューターを一意に識別するにはどうすればよいですか？

作成しているWebサイトにアクセスする各コンピューターを一意に識別する方法を見つける必要があります。これを達成する方法について誰かアドバイスはありますか？

ソリューションをすべてのマシンとすべてのブラウザで（理由の範囲内で）動作させたいので、javascriptを使用してソリューションを作成しようとしています。

私は助けに感謝します。ありがとう。

編集：

クッキーはしません。

ハードウェアの変更がコンピューターに発生していないことを前提として、基本的にコンピューターに固有で繰り返し可能なGUIDを作成する機能が必要です。私が考えている方向は、ネットワークカードのMACとウェブサイトを訪問するマシンを識別するこの性質の他の情報を取得しています。

javascriptcookiesbrowser
170
thatisvaliant

これらの人々は、ユーザーを高レベルの精度で認識するためのフィンガープリント法を開発しました：

https://panopticlick.eff.org/static/browser-uniqueness.pdf

最新のWebブラウザーが、要求に応じてWebサイトに送信するバージョンおよび構成情報を介して、「デバイスフィンガープリンティング」の対象となる度合いを調査します。 1つの可能なフィンガープリントアルゴリズムを実装し、テスト側 panopticlick.eff.org にアクセスしたブラウザの大きなサンプルからこれらのフィンガープリントを収集しました。フィンガープリントの分布には少なくとも18.1ビットのエントロピーが含まれていることがわかります。つまり、ランダムにブラウザーを選択した場合、他の286,777のブラウザーのうちの1つだけが指紋を共有すると予想されます。 FlashまたはJavaをサポートするブラウザの中で、状況はさらに悪く、平均的なブラウザは少なくとも18.8ビットの識別情報を保持しています。 FlashまたはJavaを備えたブラウザの94.2％は、サンプルで一意でした。

再訪問者を観察することにより、ブラウザの指紋が時間の経過とともにどれだけ速く変化するかを推定します。サンプルでは、​​指紋は非常に急速に変化しましたが、通常、単純なヒューリスティックでも、指紋が以前に観測されたブラウザーの指紋の「アップグレード」バージョンであると推測できました。推測の99.1％は正しく、誤検出率は0.86％のみでした。

ブラウザのフィンガープリントが実際にどのような脅威をもたらすか、それを防ぐためにどのような対策が適切かについて説明します。フィンガープリント可能性に対する保護と特定の種類のデバッグ可能性の間にはトレードオフがあり、現在のブラウザではプライバシーに対して非常に重くされています。逆説的に、指紋防止のプライバシー技術は、十分な数の人々によって使用されていない場合、自己破産する可能性があります。現在、このパラドックスの犠牲になっているプラ​​イバシー対策もありますが、そうでないものもあります...

56
Jonathan

前書き

ブラウザのみを使用してマシンを一意に識別する方法があるかどうか、またはこれからこれが行われるかどうかはわかりません。主な理由は次のとおりです。

  • ユーザーのコンピューターにデータを保存する必要があります。このデータは、ユーザーがいつでも削除できます。あらゆるマシンに固有のこのデータを再作成する方法がない限り、スタックします。
  • 検証。なりすまし、セッションハイジャックなどから保護する必要があります。

Cookieを使用せずにコンピューターを追跡する方法がある場合でも、それをバイパスする方法と、これを自動的に行うソフトウェアが常にあります。本当にコンピューターに基づいて何かを追跡する必要がある場合は、ネイティブアプリケーション（Apple Store/Android St​​ore/Windows Program /など）を作成する必要があります。

あなたが尋ねた質問に答えることはできないかもしれませんが、セッショントラッキングを実装する方法を紹介できます。セッショントラッキングを使用すると、コンピューターがサイトにアクセスする代わりに、ブラウジングセッションを追跡しようとします。セッションを追跡すると、データベーススキーマは次のようになります。

sesssion:
  sessionID: string
  // Global session data goes here

  computers: [{
     BrowserID: string
     ComputerID: string
     FingerprintID: string
     userID: string
     authToken: string
     ipAddresses: ["203.525....", "203.525...", ...]
     // Computer session data goes here
  }, ...]

セッションベースの追跡の利点：

  1. ログインしているユーザーについては、ユーザーusername/password/emailから常に同じセッションIDを生成できます。
  2. sessionIDを使用してゲストユーザーを追跡できます。
  3. 複数のユーザーが同じコンピューター（サイバーカフェなど）を使用している場合でも、ログインするとそれらを個別に追跡できます。

セッションベースの追跡の欠点：

  1. セッションはブラウザベースであり、コンピューターベースではありません。ユーザーが2つの異なるブラウザーを使用する場合、2つの異なるセッションになります。これが問題であれば、ここで読むのをやめることができます。
  2. ユーザーがログインしていない場合、セッションは期限切れになります。ユーザーがログインしていない場合、ゲストセッションを使用し、ユーザーがCookieとブラウザーキャッシュを削除すると無効になります。

実装

これを実装するには多くの方法があります。それらをすべてカバーできるとは思いませんが、これを意見の答えにするお気に入りをリストします。それを覚えておいてください。

基礎

永久Cookieと呼ばれるものを使用して、セッションを追跡します。これは、ユーザーがクッキーを削除したり、ブラウザを更新したりしても自動的に自動的に再作成されるデータです。ただし、ユーザーがCookieとブラウジングキャッシュの両方を削除しても存続しません。

これを実装するには、ブラウザのキャッシュメカニズム（ RFC ）、WebStorage API（ MDN ）、ブラウザCookie（ RFC =、 Google Analytics ）。

法的

トラッキングIDを利用するには、プライバシーポリシーと使用条件の両方にサブIDTrackingの下に追加する必要があります。 document.cookieとwindow.localStorageの両方で次のキーを使用します。

  • _ ga：Google Analyticsデータ
  • __ utma：Google AnalyticsトラッキングCookie
  • sid：SessionID

トラッキングを使用するすべてのページに、プライバシーポリシーと利用規約へのリンクを必ず含めてください。

セッションデータはどこに保存しますか？

セッションデータは、Webサイトデータベースまたはユーザーのコンピューターに保存できます。私は通常、サードパーティのアプリケーション（Googleアナリティクス/ Clicky /など）を使用する小規模なサイト（10,000未満の連続接続）で作業しているため、クライアントコンピューターにデータを保存するのが最適です。これには次の利点があります。

  1. データベース検索なし/オーバーヘッド/負荷/遅延/スペース/など.
  2. ユーザーは、迷惑なメールを書く必要なく、いつでもデータを削除できます。

と欠点：

  1. データは暗号化/復号化および署名/検証する必要があり、クライアント（それほど悪くない）およびサーバー（bah！）でCPUオーバーヘッドが発生します。
  2. ユーザーがCookieとキャッシュを削除すると、データが削除されます。 （これは本当に欲しいものです）
  3. ユーザーがオフラインになると、分析にデータを使用できなくなります。 （現在閲覧しているユーザーの分析のみ）

UUIDS

  • BrowserID：ブラウザのユーザーエージェント文字列から生成された一意のID。 Browser|BrowserVersion|OS|OSVersion|Processor|MozzilaMajorVersion|GeckoMajorVersion
  • ComputerID：ユーザーのIPアドレスとHTTPSセッションキーから生成されます。 getISP(requestIP)|getHTTPSClientKey()
  • FingerPrintID：変更された fingerprint.js に基づくJavaScriptベースのフィンガープリンティング。 FingerPrint.get()
  • SessionID：ユーザーが最初にサイトにアクセスしたときに生成されるランダムキー。 BrowserID|ComputerID|randombytes(256)
  • GoogleID：__utma Cookieから生成されます。 getCookie(__utma).uniqueid

機構

先日、ガールフレンドと ウェンディウィリアムズショー を見ていましたが、ホストが視聴者に少なくとも月に一度ブラウザの履歴を削除するようアドバイスしたとき、完全に恐怖に陥りました。ブラウザの履歴を削除すると、通常、次の効果があります。

  1. 訪問したWebサイトの履歴を削除します。
  2. Cookieとwindow.localStorage（aww man）を削除します。

最近のブラウザのほとんどは、このオプションをすぐに利用できるようにしますが、友人を恐れません。解決策があります。ブラウザには、スクリプト/画像などを保存するキャッシュメカニズムがあります。通常、履歴を削除しても、このブラウザキャッシュは残ります。必要なのは、ここにデータを保存する方法だけです。これを行うには2つの方法があります。より良い方法は、SVG画像を使用し、そのタグ内にデータを保存することです。この方法では、フラッシュを使用してJavaScriptが無効になっている場合でも、データを抽出できます。ただし、それは少し複雑なので、JSONPを使用する他のアプローチを示します（ Wikipedia ）

example.com/assets/js/tracking.js（実際はtracking.php）

var now = new Date();
var window.__sid = "SessionID"; // Server generated

setCookie("sid", window.__sid, now.setFullYear(now.getFullYear() + 1, now.getMonth(), now.getDate() - 1));

if( "localStorage" in window ) {
  window.localStorage.setItem("sid", window.__sid);
}

これで、セッションキーをいつでも取得できます。

window.__sid || window.localStorage.getItem("sid") || getCookie("sid") || ""

tracking.jsをブラウザに固定するにはどうすればよいですか？

Cache-Control 、 Last-Modified および ETag HTTPヘッダーを使用してこれを実現できます。 SessionIDをetagヘッダーの値として使用できます。

setHeaders({
  "ETag": SessionID,
  "Last-Modified": new Date(0).toUTCString(),
  "Cache-Control": "private, max-age=31536000, s-max-age=31536000, must-revalidate"
})

Last-Modifiedヘッダーは、このファイルが基本的に変更されないことをブラウザーに通知します。 Cache-Controlは、ドキュメントをキャッシュしないようにプロキシとゲートウェイに指示しますが、ブラウザに1年間キャッシュするよう指示します。

ブラウザーが次にドキュメントを要求すると、If-Modified-SinceおよびIf-None-Matchヘッダーが送信されます。これらを使用して、304 Not Modified応答を返すことができます。

example.com/assets/js/tracking.php

$sid = getHeader("If-None-Match") ?: getHeader("if-none-match") ?: getHeader("IF-NONE-MATCH") ?: ""; 
$ifModifiedSince = hasHeader("If-Modified-Since") ?: hasHeader("if-modified-since") ?: hasHeader("IF-MODIFIED-SINCE");

if( validateSession($sid) ) {
  if( sessionExists($sid) ) {
    continueSession($sid);
    send304();
  } else {
    startSession($sid);
    send304();
  }
} else if( $ifModifiedSince ) {
  send304();
} else {
  startSession();
  send200();
}

これで、ブラウザがtracking.jsを要求するたびに、サーバーは304 Not Modifiedの結果で応答し、tracking.jsのローカルコピーを強制的に実行します。

まだわかりません。説明してください

ユーザーが閲覧履歴を消去し、ページを更新するとします。ユーザーのコンピューターに残っているのは、ブラウザーのキャッシュにあるtracking.jsのコピーだけです。ブラウザーがtracking.jsを要求すると、304 Not Modified応答を受信し、受信したtracking.jsの最初のバージョンを実行します。 tracking.jsは、削除されたSessionIDを実行および復元します。

検証

Haxor Xがまだログインしている間に顧客のCookieを盗むと仮定します。どのように保護しますか？暗号化とブラウザのフィンガープリントによる救助。 SessionIDの元の定義は次のとおりです。

BrowserID|ComputerID|randomBytes(256)

これを次のように変更できます。

Timestamp|BrowserID|ComputerID|encrypt(randomBytes(256), hk)|sign(Timestamp|BrowserID|ComputerID|randomBytes(256), hk)

ここでhk = sign(Timestamp|BrowserID|ComputerID, serverKey)。

これで、次のアルゴリズムを使用してSessionIDを検証できます。

if( getTimestamp($sid) is older than 1 year ) return false;
if( getBrowserID($sid) !== createBrowserID($_Request, $_Server) ) return false;
if( getComputerID($sid) !== createComputerID($_Request, $_Server) return false;

$hk = sign(getTimestamp($sid) + getBrowserID($sid) + getComputerID($sid), $SERVER["key"]);

if( !verify(decrypt(getRandomBytes($sid)), getSignature($sid), $hk) ) return false;

return true;

Haxorの攻撃が機能するためには、次のことを行う必要があります。

  1. 同じComputerIDを使用します。つまり、被害者と同じISPプロバイダー（Tricky）が必要です。これにより、被害者は自国で法的措置を取る機会が与えられます。 Haxorは、被害者（ハード）からHTTPSセッションキーも取得する必要があります。
  2. 同じBrowserIDを使用します。誰でもユーザーエージェント文字列をスプーフィングできます（迷惑です）。
  3. 独自の偽物SessionID（非常に難しい）を作成できる。タイムスタンプを使用して暗号化/署名キーを生成するため、ボリューム攻撃は機能しません。したがって、基本的にはセッションごとに新しいキーを生成するようなものです。さらに、ランダムバイトを暗号化するため、単純な辞書攻撃も問題外です。

GoogleIDおよびFingerprintIDを（ajaxまたは非表示フィールドを介して）転送し、それらと照合することにより、検証を改善できます。

if( GoogleID != getStoredGoodleID($sid) ) return false;
if( byte_difference(FingerPrintID, getStoredFingerprint($sid) > 10%) return false;
33
Walter

可能性は flash cookies を使用することです：

  • ユビキタスな可用性（ビジターの95％はおそらくフラッシュを使用します）
  • Cookieごとにより多くのデータを保存できます（最大100 KB）
  • ブラウザ間で共有されているため、マシンを一意に識別する可能性が高い
  • ブラウザのCookieをクリアしても、フラッシュCookieは削除されません。

それらを読み書きするために、小さな（隠し）フラッシュムービーを作成する必要があります。

どんなルートを選んだとしても、ユーザーが追跡されることを選択していることを確認してください。

30
Joeri Sebrechts

所有者の協力なしにWebサイトにアクセスしているコンピューターを識別することはできません。ただし、許可された場合は、Cookieを保存して、マシンが再びサイトにアクセスしたときにマシンを識別することができます。重要なのは、訪問者が管理しているということです。 Cookieを削除して、いつでも新しい訪問者として表示できます。

30
erickson

Evercookieに一意のIDを設定してみてください（クロスブラウザーで動作します。よくある質問をご覧ください）： http://samy.pl/evercookie/

この問題を解決するために多くの大企業で使用されているThreatMetrixという会社もあります。 http://threatmetrix.com/our-solutions/solutions-by-product/trustdefender- id / 彼らは非常に高価であり、他の製品のいくつかはあまり良くありませんが、それらのデバイスIDはうまく機能します。

最後に、panopticlickアイデアのこのオープンソースjquery実装があります： https://github.com/carlo/jquery-browser-fingerprint それはきれいに見えます半分焼きましたが、拡大することができます。

それが役に立てば幸い！

21
Brian Armstrong

この科学記事で説明されている、キャンバスフィンガープリントと呼ばれる一般的な方法があります： Web Never Forgets：Persistent Tracking Mechanisms in the Wild 。探し始めたら、その使用頻度に驚くでしょう。このメソッドは、ブラウザ/ハードウェアの組み合わせごとに一貫した一意のフィンガープリントを作成します。

また、この記事では、evercookie、httpおよびFlash cookieの再生成、cookieの同期など、その他の永続的な追跡方法についても説明しています。

キャンバスのフィンガープリントについての詳細はこちら：

20
Per Quested Aronsson

HTTP接続を介して取得できる情報はごくわずかです。

  1. IP-しかし、他の人が言ったように、これは、ISPの動的割り当てポリシーのために、ほとんどのインターネットユーザーではないにしても、多くのユーザーにとっては固定されていません。

  2. Useragent String-ほとんどすべてのブラウザーは、リクエストごとにどのようなブラウザーかを送信します。ただし、これは現在、多くのブラウザでユーザーが設定できます。

  3. リクエストフィールドのコレクション-サポートされているエンコーディングなど、各リクエストとともに送信される他のフィールドがあります。これらを集約で使用すると、ユーザーのマシンの識別に役立ちますが、ブラウザに依存し、変更できます。

  4. Cookie-Cookieを設定することは、マシン、またはより具体的にはマシン上のブラウザーを識別する別の方法ですが、他の人が言ったように、これらはユーザーが削除またはオフにすることができ、ブラウザーでのみ適用できます機械。

したがって、正しい応答は、HTTP over IPプロトコルだけでは実現できないことです。ただし、CookieとIP、およびHTTP要求のフィールドの組み合わせを使用すると、それがどのマシンであるかを推測し、並べ替えることができます。ユーザーは1つのブラウザのみを使用し、多くの場合1台のマシンから使用する傾向があるため、これはかなり信頼できる場合がありますが、これは視聴者によって異なります...さらに、これは、IPの地理的位置を特定し、そのデータを使用する試みと結び付けられることさえあります。しかし、いずれにしても、常に正しい解決策はありません。

10
cdeszaq

Cookieアプローチと非Cookieアプローチの両方に欠陥があります。しかし、Cookieアプローチの欠点を許すことができるなら、ここにアイデアがあります。

サイトで既にGoogleアナリティクスを使用している場合、独自のユーザーを追跡するためのコードを記述する必要はありません。 Googleアナリティクスは、 Googleのドキュメント で説明されているように、__utma Cookie値を使用してそれを行います。また、この値を再利用することで、追加のCookieペイロードを作成することはありません。これにより、ページリクエストの効率が向上します。

そして、その値にアクセスするのに十分な簡単なコードを書くか、または このスクリプトのgetUniqueId()関数を使用できます。

9
Steve Wortham

以前のソリューションと同様に、Cookieは良い方法です。ただし、Cookieはbrowsersを識別することに注意してください。 FirefoxでWebサイトにアクセスし、その後Internet ExplorerでCookieが両方の試行で別々に保存された場合。一部のユーザーはCookieも無効にします（ただし、JavaScriptを無効にするユーザーが増えています）。

考慮すべきもう1つの方法は、IPです。ホスト名の識別（これらはダイヤルアップ/非静的IPユーザーによって異なる可能性があることに注意してください。AOLはブランケットIPも使用します）。ただし、これはネットワークを識別するだけなので、Cookieと同様に機能しない可能性があります。

8
Ross

Cookieを別に使用するための提案は、照会に使用できる識別属性の包括的なセットのみがHTTP要求ヘッダーに含まれています。そのため、これらのサブセットを使用して、ユーザーエージェント（つまり、ブラウザー）の疑似一意識別子を作成することができます。さらに、この情報のほとんどは、デフォルトでWebサーバーソフトウェアのいわゆる「アクセスログ」に既に記録されている可能性があり、そうでない場合は簡単に設定できます。次に、このログの内容を単にスキャンして、たとえばIPアドレスやユーザーエージェント文字列などで構成される各リクエストのfingerprintsを作成するユーティリティを開発できます。特定のCookieのコンテンツは、この指紋の一意性の品質に追加されます。ただし、他の多くの人がすでに述べているように、HTTPプロトコルはこの100％確実なものではありません。

6
Danny Whitt

オンラインバンキングWebサイトに一度もアクセスしたことがないマシンを使用すると、追加の認証が求められます。その後、もう一度オンラインバンキングサイトに戻ると、追加の認証を求められません... IEのすべてのCookieを削除し、認証の質問が再度表示されることを完全に期待してオンラインバンキングサイトに再ログオンしました。驚いたことに私は尋ねられなかった。これは、銀行がCookieを使用しない何らかの種類のPCタグ付けを行っていると思わせますか？

これは、銀行で使用される非常に一般的な認証タイプです。

Example-isp.comを介して銀行のWebサイトにアクセスしているとします。初めてアクセスすると、パスワードと追加の認証が求められます。合格すると、銀行はユーザー「thatisvaliant」がexample-isp.com経由でサイトにアクセスするために認証されていることを認識します。

将来的には、example-isp.com経由でサイトにアクセスするときに、（パスワードを超えて）追加の認証を要求しません。 another-isp.comを介して銀行にアクセスしようとすると、銀行は再び同じルーチンを実行します。

要約すると、銀行が特定しているのは、IPアドレスに基づいたISPやネットブロックです。明らかに、ISPのすべてのユーザーがあなたであるわけではありません。そのため、銀行はパスワードの入力を求めています。

異なる国でクレジットカードを使用するときに問題がないことを確認するために、クレジットカード会社に電話をかけたことはありますか？同じコンセプト。

6
Anirvan

プロトコルがこれを許可していないため、本当にしたいことはできません。静的IPが普遍的に使用されている場合は、それを実行できる可能性があります。そうではないので、できません。

peopleを本当に特定したい場合は、ログインしてもらいます。

彼らはおそらくあなたのウェブサイト上の別のページに移動するので、移動するときにそれらを追跡する方法が必要です。

彼らがログインし、cookie/link-parameters/beacons/whateverを介してサイト内でセッションを追跡している限り、その間は同じコンピューターを使用していることを確信できます。

最終的に、ユーザーが自分のローカルネットワークを使用しておらず、静的IPアドレスを持っていない場合に、どのコンピューターを使用しているのかを伝えるのは間違っています。

ユーザーの協力を得て、Cookieごとにユーザーが1人だけで、単一のWebブラウザーを使用する場合は、Cookieを使用してください。

4
JohnnySoftware

ソリューションをすべてのマシンとすべてのブラウザで（理由の範囲内で）動作させたいので、javascriptを使用してソリューションを作成しようとしています。

それは本当に正当な理由ではありませんnot javascriptを使用することですか？

他の人が言っているように-クッキーはおそらくあなたの最良の選択肢です-制限に注意してください。

3
Draemon

Cookieは、一意の訪問者を特定するのに役立ちません。ユーザーはCookieをクリアしてサイトを更新できます-その後、再び新しいユーザーとして分類されます。

これを行う最善の方法は、サーバー側のソリューションを実装することだと思います（データを保存する場所が必要になるため）。そのようなデータに対するニーズの複雑さに応じて、一意の訪問として分類されるものを決定する必要があります。賢明な方法は、IPアドレスが翌日戻ってきて、ユニークな訪問を許可することです。 1日に1つのIPアドレスからの複数の訪問は、ユニークとしてカウントされるべきではありません。

たとえば、PHPを使用すると、訪問者のIPアドレスを取得して、テキストファイル（またはsqlデータベース）に保存するのは簡単です。

サーバー側のソリューションはすべてのマシンで機能します。これは、ユーザーが最初にサイトをロードしたときにユーザーを追跡するためです。 javascriptはクライアント側のスクリプティングを目的としているため、JavaScriptを使用しないでください。また、ユーザーがいずれにせよそれを無効にしている可能性があります。

それが役に立てば幸いです。

3
different

fingerprintjs2 を使用できます

new Fingerprint2().get(function(result, components) {
  console.log(result) // a hash, representing your device fingerprint
  console.log(components) // an array of FP components
  //submit hash and JSON object to the server 
})

その後、すべてのユーザーを既存のものと照合し、JSONの類似性を確認することができます。したがって、指紋が変化しても、ユーザーを追跡できます。

2
Toolkit

私の判断では、私のWebサイトにアクセスしているコンピューターをプログラムで一意に識別することはできません。

次の質問があります。オンラインバンキングWebサイトに一度もアクセスしたことがないマシンを使用すると、追加の認証が求められます。その後、もう一度オンラインバンキングサイトに戻った場合、追加の認証を求められません。私の質問への回答を読んで、私はそれが関係するクッキーでなければならないと決めました。そのため、IE内のすべてのCookieを削除し、認証の質問が再度表示されることを完全に期待してオンラインバンキングサイトに再ログオンしました。驚いたことに私は尋ねられなかった。これは、銀行がCookieを使用しない何らかの種類のPCタグ付けを行っていると思わせますか？

さらに、今日多くのグーグル検索を行った後、Webサイトにアクセスするマシンを一意に識別するソリューションを販売すると主張する次の会社を見つけました。 http://www.the41.com/products.asp 。

この矛盾する情報をさらに明確にできれば、すべての良い情報に感謝します。

2
thatisvaliant

これは、CookieとFlash Cookieの組み合わせを使用して行います。 GUIDを作成し、Cookieに保存します。 Cookieが存在しない場合は、フラッシュCookieから読み取ろうとします。それでも見つからない場合は、作成してフラッシュCookieに書き込みます。これにより、同じGUIDをブラウザー間で共有できます。

2
Eric Hogue

クッキーはあなたが探しているものかもしれません。これは、ほとんどのWebサイトが訪問者を一意に識別する方法です。

1
Steve

ユーザーが制御できるようにしたくない場合は、できません。ウェブはそのように機能しません。あなたが期待できる最高のものは、いくつかの発見的方法です。

訪問者にソフトウェアをインストールし、TCPAを使用するよう強制するオプションである場合、何かを引き出すことができるかもしれません。

0
John Nilsson

トリック：

  1. 2つの登録ページを作成します。

    最初の登録ページ：メールまたはセキュリティチェックなし（ユーザー名とパスワードのみ）

    2番目の登録ページ：セキュリティレベルが高い（電子メール検証要求とセキュリティイメージなど）

  2. 顧客満足度と簡単な登録のために、デフォルトの登録ページは（最初の登録ページ）であるべきですが、（最初の登録ページ）には隠された制限があります。 IPの制限です。ブロックページを表示する代わりに、IPが2回（たとえば1時間未満）登録を試みた場合。 （Second Registration Page）を自動的に表示できます。

  3. （最初の登録ページ）で設定できます（例：1 ipからの2回の試行を1時間または24時間だけブロックします）および1時間後（たとえば）1時間後に、そこからアクセスを開くことができます自動的にIP

注：（最初の登録ページ）と（2番目の登録ページ）は別々のページに入れないでください。 1ページだけ作成します。 （例：register.php）、最初のPHPスタイルと2番目のPHPスタイルを切り替えるのが賢明です

0
Mahdi Jazini

私の投稿は解決策ではないかもしれませんが、この機能が実装されている例を提供できます。

コンピュータからwww.supertorrents.orgのサインアップページに初めてアクセスする場合は、問題ありません。ただし、ページを更新するか、ページを再度開くと、以前にそのページにアクセスしたことが識別されます。本当の美しさはここにあります-Windowsや他のOSを再インストールしても識別されます。

CPU IDが保存されていることをどこかで読みました。私は彼らがそれをどのように行うか見つけることができませんでしたが、私はそれを真剣に疑い、彼らはそれを行うためにMACアドレスを使用するかもしれません。

howを見つけたら共有します。

0
Mr Programmer