200

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

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

クッキーはしません。

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

4

22 に答える 22

83

序章

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

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

Cookie を使用せずにコンピュータを追跡する方法があるとしても、それをバイパスする方法と、これを自動的に行うソフトウェアが常に存在します。コンピューターに基づいて何かを追跡する必要がある場合は、ネイティブ アプリケーション (Apple Store / Android Store / 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. ログインしているユーザーの場合、いつでもユーザーから同じセッション ID を生成できますusername// 。passwordemail
  2. を使用して、引き続きゲスト ユーザーを追跡できますsessionID。
  3. 複数の人が同じコンピュータ (例: サイバー カフェ) を使用している場合でも、ログインしている場合は個別に追跡できます。

セッション ベースのトラッキングの欠点:

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

実装

これを実装するには多くの方法があります。それらすべてをカバーできるとは思わないので、お気に入りをリストするだけで、これは独断的な答えになります。心に留めておいてください。

基本

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

これを実装するには、ブラウザーのキャッシュ メカニズム ( RFC )、WebStorage API ( MDN )、およびブラウザーの Cookie ( RFC、Google Analytics ) を使用します。

法的

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

  • _ga : Google アナリティクスのデータ
  • __utma : Google アナリティクス トラッキング Cookie
  • sid : セッション ID

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

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

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

  1. データベース ルックアップ / オーバーヘッド / 負荷 / レイテンシ / スペースなどはありません。
  2. ユーザーは、迷惑なメールを書く必要なく、いつでも自分のデータを削除できます。

と欠点:

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

UUIDS

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

機構

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

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

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

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 ヘッダーを使用して実現できます。SessionIDetag ヘッダーの as 値を使用できます。

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 Modifiedtracking.jstracking.jsSessionID

検証

ログインしている間に 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(getTimestamp($sid) + getBrowserID($sid) + getComputerID($sid) + decrypt(getRandomBytes($sid), hk), getSignature($sid), $hk) ) return false;

return true;

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

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

GoogleID(ajax または隠しフィールドを介して) andを転送し、FingerprintIDそれらと照合することで、検証を改善できます。

if( GoogleID != getStoredGoodleID($sid) ) return false;
if( byte_difference(FingerPrintID, getStoredFingerprint($sid) > 10%) return false;
于 2017-01-10T18:14:54.403 に答える
58

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

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％でした。 。

プライバシーの脅威となるブラウザのフィンガープリントが実際にもたらすものと、それを防ぐために適切な対策について説明します。フィンガープリント可能性に対する保護と特定の種類のデバッグ可能性の間にはトレードオフがあり、現在のブラウザーではプライバシーに対して大きな重みがあります。逆説的ですが、指紋防止プライバシーテクノロジーは、十分な数の人々が使用していない場合、自滅する可能性があります。現在、一部のプライバシー対策がこのパラドックスの犠牲になっていることを示していますが、他の対策はそうではありません...

于 2010-07-20T07:14:42.807 に答える
31

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

于 2008-10-19T15:42:42.257 に答える
30

フラッシュ Cookieを使用している可能性があります。

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

それらを読み書きするには、小さな (隠れた) Flash ムービーを作成する必要があります。

どのルートを選択するにしても、ユーザーが追跡されることを選択していることを確認してください。そうしないと、ユーザーのプライバシーを侵害し、悪者の 1 つになることになります。

于 2008-10-19T16:10:14.323 に答える
21

evercookie に一意の ID を設定してみてください (クロス ブラウザーで動作します。FAQ を参照してください): 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 現在はかなり中途半端に見えますが、拡張することができます。

それが役に立てば幸い！

于 2012-05-13T18:29:07.917 に答える
12

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

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

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

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

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

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

于 2008-10-19T19:57:35.830 に答える
10

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

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

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

于 2012-08-28T15:18:13.383 に答える
8

以前のソリューションと同様に、Cookie は適切な方法ですが、ブラウザーを識別することに注意してください。Firefox で Web サイトにアクセスしてから Internet Explorer でアクセスした場合、Cookie は両方の試行で別々に保存されます。Cookie を無効にするユーザーもいます (ただし、JavaScript を無効にするユーザーが増えています)。

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

于 2008-10-19T15:50:18.640 に答える
6

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

于 2008-10-20T02:40:30.200 に答える
6

オンライン バンキングの Web サイトに一度もアクセスしたことがないマシンを使用すると、追加の認証を求められます。次に、もう一度オンライン バンキング サイトに戻っても、追加の認証を求められません... IE のすべての Cookie を削除し、オンライン バンキング サイトに再ログインして、もう一度認証の質問をされることを期待しました。驚いたことに、私は尋ねられませんでした。これは、銀行がクッキーを含まないある種の PC タグ付けを行っていると信じさせるものではありませんか?

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

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

今後、example-isp.com 経由でサイトにアクセスするときに、(パスワード以外の) 追加の認証を要求することはなくなります。another-isp.com 経由で銀行にアクセスしようとすると、銀行は同じ手順を繰り返します。

要約すると、銀行が識別しているのは、IP アドレスに基づいた ISP および/またはネットブロックです。明らかに、ISP のすべてのユーザーがあなたであるとは限りません。そのため、銀行は依然としてパスワードを要求します。

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

于 2008-10-28T23:00:14.813 に答える
4

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

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

それらは Web サイトの別のページに移動する可能性が高いため、それらの移動を追跡する方法が必要です。

彼らがログインしていて、Cookie/リンクパラメータ/ビーコンなどを介してサイト内で彼らのセッションを追跡している限り、その間、彼らが同じコンピューターを使用していることを確信できます.

最終的に、ユーザーが独自のローカル ネットワークを使用しておらず、静的 IP アドレスを持っていない場合、これでどのコンピューターを使用しているかがわかると言うのは正しくありません。

あなたがしたいことがユーザーの協力を得て行われており、Cookie ごとに 1 人のユーザーしかなく、単一の Web ブラウザーを使用している場合は、Cookie を使用してください。

于 2008-10-19T17:32:05.920 に答える
3

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

これは、 javascript を使用しない正当な理由ではないでしょうか?

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

于 2008-10-19T16:26:24.743 に答える
2

評決は、自分のWebサイトにアクセスしているコンピューターをプログラムで一意に識別できないことだと思います。

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

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

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

于 2008-10-20T01:29:20.543 に答える
2

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

于 2008-11-05T19:08:43.727 に答える
2

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

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

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

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

それが役立つことを願っています。

于 2008-10-19T15:49:37.843 に答える
1

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

于 2008-10-19T15:36:56.670 に答える
0

ユーザーがコントロールしたくないと仮定すると、それはできません。Web はそのようには機能しません。期待できる最善の方法は、いくつかのヒューリスティックです。

訪問者に何らかのソフトウェアのインストールと TCPA の使用を強制することがオプションである場合、何かを実行できる可能性があります。

于 2008-10-19T17:18:09.833 に答える
-1

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

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

CPU IDが保存されていることをどこかで読みました。彼らがどのようにそれを行うのかはわかりませんでしたが、私はそれを真剣に疑っています.MACアドレスを使用してそれを行う可能性があります.

その方法を見つけたら、必ず共有します。

于 2013-05-04T17:04:02.203 に答える
-2

トリック：

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

    最初の登録ページ:電子メールやセキュリティ チェックなし (ユーザー名とパスワードのみ)

    2 番目の登録ページ:高セキュリティ レベル (電子メール認証要求とセキュリティ イメージなど)

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

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

注意: (最初の登録ページ)と(2 番目の登録ページ)は別々のページにしないでください。あなたはたった1ページを作ります。(例: register.php)、最初の PHP スタイルと 2 番目の PHP スタイルの切り替えをスマートにします。

于 2016-11-06T13:36:32.777 に答える