웹 사이트를 방문하는 컴퓨터를 고유하게 식별하려면 어떻게 해야 합니까?

웹 사이트를 방문하는 컴퓨터를 고유하게 식별하려면 어떻게 해야 합니까?

작성하는 웹 사이트에 접속하는 각 컴퓨터를 일의로 특정할 필요가 있습니다.이걸 어떻게 해야 할지 조언해 주실 분?

모든 기계와 모든 브라우저에서 (합리적인 범위 내에서) 솔루션이 작동하기를 원하기 때문에 javascript를 사용하여 솔루션을 작성하려고 합니다.

쿠키로는 안 돼요.

기본적으로 컴퓨터에 고유한 GUID를 작성하고 하드웨어 변경은 발생하지 않았다고 가정할 때 반복할 수 있어야 합니다.제가 생각하고 있는 방향은 네트워크 카드의 MAC 및 웹 사이트를 방문하는 머신을 식별할 수 있는 기타 정보를 얻는 것입니다.

서론

브라우저만으로 기계를 일의로 식별할 수 있는 방법이 있는지 없을지는 모르겠습니다.주된 이유는 다음과 같습니다.

• 사용자 컴퓨터에 데이터를 저장해야 합니다.이 데이터는 사용자가 언제든지 삭제할 수 있습니다.각 머신에 고유한 이 데이터를 재생성할 방법이 없는 한 꼼짝할 수 없습니다.
• 확인.스푸핑, 세션 하이잭 등을 방지해야 합니다.

쿠키를 사용하지 않고 컴퓨터를 추적하는 방법이 있더라도 이를 자동으로 실행하는 소프트웨어와 우회하는 방법이 항상 있습니다.컴퓨터를 기반으로 무언가를 추적해야 할 경우 네이티브 애플리케이션(Apple Store/Android Store/Windows 프로그램 등)을 작성해야 합니다.

질문하신 내용에 대한 답변은 드릴 수 없지만 세션 트래킹 구현 방법을 보여 드릴 수 있습니다.세션 추적을 사용하면 컴퓨터가 사이트를 방문하는 대신 검색 세션을 추적합니다.세션을 추적하면 데이터베이스 스키마는 다음과 같습니다.

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/password/email.
2. 다음 방법으로 게스트 사용자를 추적할 수 있습니다.sessionID.
3. 여러 사람이 같은 컴퓨터(즉, 사이버 카페)를 사용하는 경우에도 로그인하면 개별적으로 추적할 수 있습니다.

세션 기반 추적의 단점:

1. 세션은 브라우저 기반이며 컴퓨터 기반이 아닙니다.사용자가 2개의 다른 브라우저를 사용하는 경우 2개의 세션이 발생합니다.만약 이것이 문제라면, 당신은 여기서 읽기를 멈출 수 있습니다.
2. 사용자가 로그인하지 않으면 세션이 만료됩니다.사용자가 로그인하지 않은 경우 게스트세션을 사용합니다.게스트 세션은 사용자가 쿠키와 브라우저 캐시를 삭제하면 비활성화됩니다.

실행

이것을 실장하는 방법에는 여러 가지가 있습니다.내가 그것들을 다 다룰 수 있을 것 같지 않다. 단지 내가 좋아하는 것을 나열할 것이다. 이것이 독단적인 답변이 될 것이다.명심하세요.

기본

Forever cookie라고 하는 것을 사용하여 세션을 추적합니다.이는 사용자가 쿠키를 삭제하거나 브라우저를 업데이트하더라도 자동으로 재생성되는 데이터입니다.그러나 사용자가 쿠키와 브라우징 캐시를 모두 삭제해도 살아남을 수 없습니다.

이를 구현하기 위해 브라우저 캐싱 메커니즘(RFC), WebStorage API(MDN) 및 브라우저 쿠키(RFC, Google Analytics)를 사용합니다.

합법적인

추적 ID를 사용하려면 가급적 추적 하위 제목 아래에 개인 정보 보호 정책 및 사용 조건에 ID를 추가해야 합니다.양쪽에서 다음 키를 사용합니다.document.cookie그리고.window.localStorage:

• _ga: Google Analytics 데이터
• __utma: Google Analytics 추적 쿠키
• sid: 세션아이디

추적을 사용하는 모든 페이지에 개인 정보 보호 정책 및 사용 약관에 대한 링크를 포함해야 합니다.

세션 데이터는 어디에 저장합니까?

웹 사이트 데이터베이스 또는 사용자 시스템에 세션 데이터를 저장할 수 있습니다.서드파티 애플리케이션(Google Analytics/Clicky 등)을 사용하는 소규모 사이트(연속 접속 수 10,000개 이상)에서 작업하기 때문에 클라이언트 컴퓨터에 데이터를 저장하는 것이 가장 좋습니다.여기에는 다음과 같은 이점이 있습니다.

1. 데이터베이스 조회/오버헤드/로드/지연/공간 등이 없습니다.
2. 사용자는 나에게 짜증나는 이메일을 쓸 필요 없이 언제든지 데이터를 삭제할 수 있습니다.

단점:

1. 데이터는 암호화/복호화/서명/검증되어야 하며 이로 인해 클라이언트(그렇게 나쁘지 않음) 및 서버(bah!)에서 CPU 오버헤드가 발생합니다.
2. 데이터는 사용자가 쿠키 및 캐시를 삭제하면 삭제됩니다.(이게 내가 정말 원하는 거야)
3. 사용자가 오프라인 상태가 되면 데이터를 분석에 사용할 수 없습니다.(현재 참조 중인 사용자만 해당)

UUIDS

• 브라우저 ID:브라우저 사용자 에이전트 문자열에서 생성된 고유 ID입니다. Browser|BrowserVersion|OS|OSVersion|Processor|MozzilaMajorVersion|GeckoMajorVersion
• 컴퓨터ID: 사용자의 IP 주소와 HTTPS 세션 키에서 생성됩니다. getISP(requestIP)|getHTTPSClientKey()
• 지문ID: 변경된 핑거프린트에 기반한 JavaScript 기반 핑거프린트.js. FingerPrint.get()
• SessionID : 사용자가 처음 사이트를 방문했을 때 생성되는 랜덤 키입니다. BrowserID|ComputerID|randombytes(256)
• Google ID:생성원__utmacookie. getCookie(__utma).uniqueid

메커니즘

얼마 전 여자친구와 함께 웬디 윌리엄스 쇼를 보던 중 한 달에 한 번은 브라우저 기록을 삭제하라고 사회자가 시청자들에게 조언했을 때 완전히 공포에 떨었다.브라우저 이력을 삭제하면 일반적으로 다음과 같은 영향이 있습니다.

1. 방문한 웹 사이트의 기록을 삭제합니다.
2. cookie를 삭제하고window.localStorage(와우맨)

대부분의 최신 브라우저는 이 옵션을 쉽게 사용할 수 있도록 하지만 친구를 두려워하지 않습니다.해결책이 있으니까브라우저에는 스크립트/이미지 및 기타 정보를 저장하는 캐싱 메커니즘이 있습니다.일반적으로 이력을 삭제해도 이 브라우저 캐시는 그대로 유지됩니다.여기에 데이터를 저장하는 방법만 있으면 됩니다.두 가지 방법이 있습니다.SVG 이미지를 사용하여 태그에 데이터를 저장하는 것이 좋습니다.이렇게 하면 플래시를 사용하여 JavaScript가 비활성화되어도 데이터를 추출할 수 있습니다.다만, 조금 복잡하기 때문에, JSONP(Wikipedia)를 사용하는 다른 어프로치에 대해 설명하겠습니다.

example.com/assets/js/tracking.js (실제로는 tracking.filename)

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 헤더 값:

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

Last-Modifiedheader는 브라우저에 이 파일이 기본적으로 변경되지 않음을 알려줍니다. 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가 고객이 로그인한 상태에서 쿠키를 훔쳤다고 가정합니다.어떻게 보호하죠?암호 및 브라우저 지문 채취를 통해 구조 작업을 수행할 수 있습니다.델의 최초 정의를 기억해 주십시오.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; 

이제 헥소르의 공격이 효과가 있으려면 다음과 같이 해야 합니다.

1. 같다ComputerID즉, 희생자와 같은 ISP 프로바이더가 필요합니다(Tricky).이것은 우리의 희생자가 그들의 나라에서 법적 조치를 취할 수 있는 기회를 줄 것이다.Haxor는 공격 대상자(Hard)로부터 HTTPS 세션키도 취득해야 합니다.
2. 같다BrowserID사용자 에이전트 문자열(Annoying)은 누구나 스푸핑할 수 있습니다.
3. 만의 가짜를 수 .SessionID(서양속담, 친구속담)암호화/서명 키를 생성하기 위해 타임스탬프를 사용하기 때문에 볼륨 어택은 작동하지 않습니다.따라서 기본적으로 각 세션에 대해 새 키를 생성하는 것과 같습니다.게다가 랜덤 바이트를 암호화하기 때문에 간단한 사전 공격도 불가능합니다.

하면 될 수 있습니다.GoogleID ★★★★★★★★★★★★★★★★★」FingerprintID필드를 ) 및 에 대해

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

이 사람들은 높은 수준의 정확도로 사용자를 인식하기 위한 지문 채취 방법을 개발했습니다.

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

최신 웹 브라우저가 요구 시 웹 사이트로 전송하는 버전 및 구성 정보를 통해 "디바이스 핑거프린트"의 대상이 되는 정도를 조사합니다.가능한 핑거프린트 알고리즘을 1개 실장하고 테스트 측 panopticlick.eff.org에 접속한 브라우저의 샘플로부터 이러한 지문을 수집했습니다.지문 분포에 적어도 18.1비트의 엔트로피가 포함되어 있는 것을 알 수 있습니다.즉, 브라우저를 무작위로 선택하면 286,777개의 다른 브라우저 중 1개만 지문을 공유할 것으로 예상됩니다.Flash 또는 Java를 지원하는 브라우저에서는 상황이 더 악화되어 평균 브라우저가 최소 18.8비트의 식별 정보를 가지고 있습니다. Flash 또는 Java를 탑재한 브라우저의 94.2%는 이 샘플에서 고유했습니다.

돌아오는 방문자를 관찰함으로써 브라우저 지문이 시간이 지남에 따라 얼마나 빠르게 변화할 수 있는지 추정합니다.이 샘플에서는 지문이 매우 빠르게 변화했지만 단순한 경험적 접근법이라도 일반적으로 지문이 이전에 관찰된 브라우저 지문의 "업그레이드된" 버전일 때 추측의 99.1%가 정확하고 잘못된 긍정률은 0.86%에 불과했다.

브라우저 핑거프린트가 실제로 어떤 영향을 미치는지, 그리고 이를 방지하기 위해 어떤 대책이 적절한지에 대해 논의합니다.지문 보호와 특정 종류의 디버깅 가능성 사이에는 트레이드오프가 존재하며, 이는 현재 브라우저에서는 프라이버시에 대해 매우 큰 비중을 두고 있습니다.역설적으로 지문인식 방지 프라이버시 테크놀로지는 충분한 수의 사용자가 사용하지 않으면 자멸할 수 있습니다.우리는 현재 일부 프라이버시 조치가 이 역설의 희생양이 되고 있지만 다른 것들은 그렇지 않다는 것을 보여 줍니다.

웹 사이트에 접속하는 컴퓨터는 소유자의 협조 없이 식별할 수 없습니다.그러나 사용자가 허락하는 경우, 쿠키를 저장하여 머신이 사이트를 다시 방문할 때 머신을 식별할 수 있습니다.중요한 것은 방문자가 통제할 수 있다는 것입니다. 언제든지 쿠키를 제거하고 새로운 방문자로 나타날 수 있습니다.

플래시 쿠키를 사용할 수 있습니다.

• 유비쿼터스 가용성(방문자의 95%가 플래시를 사용할 수 있음)
• 쿠키당 더 많은 데이터를 저장할 수 있습니다(최대 100KB).
• 브라우저 간에 공유되므로 머신을 고유하게 식별할 수 있습니다.
• 브라우저 쿠키를 지워도 플래시 쿠키는 삭제되지 않습니다.

읽고 쓰려면 작은(숨긴) 플래시 동영상을 만들어야 합니다.

어떤 경로를 선택하든 사용자가 추적에 참여하도록 하십시오. 그렇지 않으면 사용자의 사생활을 침해하고 나쁜 사람이 될 수 있습니다.

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 이것은 현재 거의 구워지지 않은 것처럼 보이지만, 확장될 수 있습니다.

도움이 됐으면 좋겠다!

이 과학 기사에서 설명하는 캔버스 지문 채취라고 불리는 인기 있는 방법이 있습니다.웹에서 잊지 않는 것: 자연에서의 지속적 추적 메커니즘일단 찾기 시작하면 얼마나 자주 사용하는지 놀랄 것이다.이 메서드는 브라우저/하드웨어 조합별로 일관된 고유한 지문을 생성합니다.

이 문서에서는 evercookies, http 및 Flash cookie 응답, cookie 동기화 등 기타 영속적인 추적 방법에 대해서도 설명합니다.

캔버스 지문 채취에 대한 자세한 내용은 다음을 참조하십시오.

• 픽셀 퍼펙트:HTML5에서의 지문 인증 캔버스
• https://en.wikipedia.org/wiki/Canvas_fingerprinting

HTTP 연결을 통해 얻을 수 있는 정보는 소량뿐입니다.

1. IP - 그러나 다른 사용자가 말했듯이 ISP의 동적 할당 정책에 따라 대부분의 인터넷 사용자가 이 문제를 해결할 수는 없습니다.

2. Useragent String - 거의 모든 브라우저가 요청 시 어떤 브라우저인지 보냅니다.그러나 이것은 오늘날 많은 브라우저에서 사용자가 설정할 수 있습니다.

3. 요청 필드 모음 - 지원되는 인코딩 등 각 요청과 함께 전송되는 다른 필드가 있습니다.이러한 정보를 집약으로 사용하면 사용자의 머신을 식별하는 데 도움이 되지만 브라우저에 따라 다르므로 변경할 수 있습니다.

4. 쿠키 - 쿠키를 설정하는 것은 머신, 특히 머신상의 브라우저를 식별하는 또 다른 방법이지만, 다른 사용자가 말한 것처럼 이러한 쿠키를 삭제하거나 끌 수 있습니다.또한 이 기능은 브라우저에서만 적용되며 머신은 사용할 수 없습니다.

따라서 올바른 응답은 HTTP over IP 프로토콜만으로는 원하는 것을 달성할 수 없다는 것입니다.그러나 쿠키와 IP 및 HTTP 요청 필드를 조합하여 사용하면 어떤 기계인지 추측할 수 있습니다.사용자는 한 대의 브라우저만 사용하는 경향이 있고, 많은 경우 한 대의 머신에서 사용하기 때문에 상당히 완화될 수 있지만, 이는 시청자에 따라 달라집니다.기술자들은 이런 것들을 망치고 더 많은 기계/기계를 사용할 가능성이 높습니다.게다가 이것은, IP 의 위치를 특정해, 그 데이터를 사용하는 시도와도 관련될 가능성이 있습니다.그러나 어떤 경우에도 항상 올바른 해결책은 없습니다.

쿠키와 쿠키 이외의 접근법에는 모두 결함이 있습니다.하지만 쿠키 접근법의 단점을 용서할 수 있다면, 한 가지 아이디어가 있습니다.

사이트에서 Google Analytics를 이미 사용하고 있는 경우에는 고유한 사용자를 추적하기 위해 코드를 작성할 필요가 없습니다.는 Google Analytics를 을 제공합니다.__utma쿠키 값(Google 설명서에 설명되어 있음)을 참조하십시오.또한 이 값을 재사용하면 추가 쿠키 페이로드가 생성되지 않으므로 페이지 요청에 대한 효율성이 향상됩니다.

그 값에 액세스 할 수 있는 코드를 간단하게 작성할 수 있습니다.또, 이 스크립트의 getUniqueId()★★★★★★ 。

이전 솔루션 쿠키는 좋은 방법이지만 브라우저를 식별하는 데 유의하십시오.Firefox와 Internet Explorer의 웹 사이트를 방문하면 두 시도 모두 쿠키가 별도로 저장됩니다.일부 사용자는 쿠키를 사용하지 않도록 설정하기도 합니다(단, JavaScript를 사용하지 않도록 설정하는 사람이 더 많습니다).

고려해야 할 또 하나의 방법은 IP와 호스트명의 식별입니다(다이얼업/비정적 IP 사용자에 따라 다를 수 있습니다.AOL은 포괄적인 IP도 사용합니다).다만, 이것은 네트워크만을 식별하기 때문에, 쿠키와 같이 동작하지 않는 경우가 있습니다.

cookie를 사용하기 위한 권장사항은 HTTP 요청 헤더에 포함되어 있습니다.이것은 조회할 수 있는 유일한 포괄적인 식별 속성 세트입니다.따라서 이들 서브셋을 사용하여 사용자 에이전트(브라우저 등)의 의사 고유 식별자를 작성할 수 있습니다.게다가 이러한 정보의 대부분은, 디폴트로 Web 서버 소프트웨어의 이른바 「액세스 로그」에 이미 기록되고 있는 경우가 있습니다.그렇지 않은 경우, 간단하게 설정할 수 있습니다.그 후, 이 로그의 내용을 스캔 하는 것만으로, 예를 들면, IP 주소나 유저 에이전트 문자열 등으로 구성된 각 요구의 핑거 프린트를 작성하는 유틸리티가 개발됩니다.특정 쿠키의 내용을 포함하여 더 많은 데이터를 사용할 수 있으므로 이 지문의 고유성이 더욱 향상됩니다.다른 많은 사람들이 이미 언급했듯이 HTTP 프로토콜이 100% 오류를 방지하지는 않습니다. 기껏해야 꽤 좋은 지표일 뿐입니다.

온라인 뱅킹 사이트에 접속하지 않은 기기를 사용할 경우 추가 인증을 요청받습니다.그 후 다시 온라인 뱅킹 사이트에 접속해도 추가 인증이 요구되지 않습니다.IE의 모든 쿠키를 삭제하고 인증 질문을 다시 받기를 기대하며 온라인 뱅킹 사이트에 다시 로그인했습니다.놀랍게도 나는 질문을 받지 않았다.이것은 은행이 쿠키를 포함하지 않는 일종의 PC 태깅을 하고 있다고 믿게 하지 않나요?

이것은 은행에서 사용되는 매우 일반적인 유형의 인증입니다.

example-isp.com을 통해 은행 웹 사이트에 접속한다고 가정해 보십시오.처음 접속했을 때 패스워드를 입력해, 추가 인증을 요구할 수 있습니다.일단 합격하면 은행은 사용자가 example-isp.com을 통해 사이트에 접속할 수 있도록 "thatisvaliant"라는 인증을 받은 것을 알게 됩니다.

앞으로는 example-isp.com을 통해 사이트에 접속할 때 추가 인증(비밀번호 입력)을 요구하지 않습니다.만약 당신이 another-isp.com을 통해 은행에 접속하려고 한다면, 은행은 다시 같은 절차를 밟을 것입니다.

요약하면, 은행이 특정하는 것은, 고객의 IP 주소에 근거해 ISP나 넷 블록입니다.ISP의 모든 사용자가 당신이라고는 할 수 없기 때문에 은행은 여전히 당신에게 비밀번호를 요구합니다.

다른 나라에서 신용카드를 사용할 때 문제가 없는지 확인하기 위해 신용카드 회사에 전화를 걸어본 적이 있습니까?같은 콘셉트.

정말이지, 프로토콜이 허락하지 않기 때문에 당신이 원하는 것을 할 수 없습니다.고정 IP 가 일반적으로 사용되고 있는 경우는, 그것을 실행할 수 있을 가능성이 있습니다.그들은 그렇지 않기 때문에, 당신은 할 수 없다.

사용자를 식별하려면 로그인하도록 하십시오.

웹 사이트의 다른 페이지로 이동하기 때문에 이동하는 동안 추적하는 방법이 필요합니다.

사용자가 로그인하여 쿠키/링크 파라미터/비콘 등을 통해 사이트 내에서 세션을 추적하는 한, 그 동안 같은 컴퓨터를 사용하고 있음을 알 수 있습니다.

최종적으로는 사용자가 자신의 로컬네트워크를 사용하고 있지 않고 고정 IP 주소가 없는 경우, 사용하고 있는 컴퓨터를 나타내는 것은 올바르지 않습니다.

사용자의 협조를 얻어 쿠키당 사용자가 1명이고 웹 브라우저를 1개만 사용하는 경우 쿠키를 사용하십시오.

지문을 사용할 수 있습니다.js2

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 유사성을 확인할 수 있으므로 지문이 변이되어도 추적할 수 있습니다.

모든 기계와 모든 브라우저에서 (합리적인 범위 내에서) 솔루션이 작동하기를 원하기 때문에 javascript를 사용하여 솔루션을 작성하려고 합니다.

javascript를 사용하지 않는 것은 정말 좋은 이유 아닌가요?

다른 사람들이 말했듯이, 쿠키가 가장 좋은 옵션일 것입니다.- 제한 사항만 알아두십시오.

제 웹 사이트를 방문하는 컴퓨터를 프로그래밍 방식으로 고유하게 식별할 수 없다는 평결이 내려진 것 같습니다.

저는 다음과 같은 질문이 있습니다.온라인 뱅킹 사이트에 접속하지 않은 기기를 사용할 경우 추가 인증을 요청받습니다.그리고 나서 내가 다시 온라인 뱅킹 사이트에 접속하면 추가 인증을 요청받지 않는다.내 질문에 대한 답을 읽으면서 나는 쿠키가 관련된 것이 틀림없다고 결정했다.그래서 IE에 있는 모든 쿠키를 삭제하고 인증 질문을 다시 받기를 기대하며 제 온라인 뱅킹 사이트에 다시 접속했습니다.놀랍게도 나는 질문을 받지 않았다.이것은 은행이 쿠키를 포함하지 않는 일종의 PC 태깅을 하고 있다고 믿게 하지 않나요?

게다가, 오늘 많은 구글 검색 후에, 나는 웹사이트를 방문하는 기계를 독특하게 식별하는 솔루션을 판매한다고 주장하는 다음 회사를 찾았습니다.http://www.the41.com/products.asp 를 참조해 주세요.

이 상반된 정보를 좀 더 명확하게 해주시면 감사하겠습니다.

쿠키와 플래시 쿠키를 조합하여 사용합니다.GUID를 생성하여 쿠키에 저장합니다.쿠키가 존재하지 않는 경우 플래시 쿠키에서 읽어 보십시오.그래도 찾을 수 없으면 만들고 플래시 쿠키에 씁니다.이렇게 하면 브라우저 간에 동일한 GUID를 공유할 수 있습니다.

쿠키가 당신이 찾고 있는 것일지도 모릅니다.이것은 대부분의 웹사이트가 방문자를 고유하게 식별하는 방법입니다.

쿠키는 고유한 방문자를 결정하는 데 유용하지 않습니다.사용자는 쿠키를 지우고 사이트를 새로 고칠 수 있습니다. 그러면 다시 새 사용자로 분류됩니다.

이것을 실시하려면 , 서버측 솔루션을 실장하는 것이 최선이라고 생각합니다(데이터를 격납하는 장소가 필요하게 됩니다).이러한 데이터에 대한 요구의 복잡성에 따라 고유 방문으로 분류되는 항목을 결정해야 합니다.적절한 방법은 IP 주소가 다음날 반환되어 고유한 방문을 받을 수 있도록 하는 것입니다.1개의 IP 주소에서1일 동안 여러 번 방문해도 일의로 간주되지 않습니다.

예를 들어 PHP를 사용하면 방문자의 IP 주소를 가져와 텍스트 파일(또는 SQL 데이터베이스)에 저장하는 것이 간단해집니다.

서버측 솔루션은 모든 머신에서 동작합니다.사용자가 사이트를 처음 로드할 때 추적하기 때문입니다.javascript는 클라이언트 측 스크립팅용으로 사용하기 때문에 사용하지 마십시오.또한 어떤 경우에도 사용자가 비활성화 시킬 수 있습니다.

도움이 됐으면 좋겠다.

사용자가 제어할 수 없도록 하려면 제어할 수 없습니다.웹은 그런 식으로 작동하지 않습니다. 당신이 기대할 수 있는 최선의 방법은 몇 가지 휴리스틱스입니다.

방문자에게 소프트웨어를 설치하고 TCPA를 사용하도록 강요하는 옵션이라면 뭔가 할 수 있을 것입니다.

저는 간단한 것부터 복잡한 것까지 제 아이디어를 발표하겠습니다.위의 모든 경우 세션을 작성할 수 있으며, 이 문제는 기본적으로 세션과 요구를 일치시키기 위해 변환됩니다.

a) (클라이언트하드웨어를 사용하여 어떤 종류의 세션 ID/패킷을 알기 쉽게 저장합니다(개인 정보/보안 문제가 상당히 있으므로 저장하는 모든 것을 해시하십시오).솔루션에는 다음과 같은 것이 있습니다.

• 쿠키 저장소
• 브라우저 스토리지/WebDB/(더 이국적인 브라우저 솔루션)
• 파일을 저장할 수 있는 권한이 있는 확장자를 지정합니다.

위의 문제는 사용자가 원할 경우 캐시를 비울 수 있다는 것입니다.

b) (난이도: 중간) 로그인 기반 인증.대부분의 최신 웹 프레임워크는 이러한 솔루션을 제공합니다.핵심은 사용자가 자발적으로 자신을 특정할 수 있도록 하는 것입니다.단, 아키텍처의 복잡성은 증가합니다.

위의 내용은 복잡성이 가중되어 기본적으로 공개되지 않는 콘텐츠를 만드는 데 어려움을 겪고 있습니다.

c) (난이도: 하드 R&D) 메타데이터에 근거한 식별 (브라우저 ip/language /browser / 기타 사생활 침해 사항)사용자에게 알리거나 소송을 당할 경우)불완전한 솔루션은 더 복잡해질 수 있습니다(특정 빈도로 타이핑하거나 특정 패턴의 마우스를 사용하여 ML 솔루션을 적용하기도 합니다).청구된 해결 방법

명확한 설명을 원하지 않아도 사용자 이후 가장 강력한 사용자임을 확인할 수 있습니다.이는 사생활의 직접적인 침해이며(GDPR 참조), 완벽하지 않다(예: ip can change).

제 투고는 해결책이 아닐 수 있지만, 이 기능이 구현된 예를 들어 드리겠습니다.

www.supertorrents.org 고치거나 한 적이 알 수 있습니다.그러나 페이지를 새로 고치거나 다시 열면 이전에 페이지를 방문했음을 나타냅니다.진정한 장점은 Windows 또는 다른 OS를 재설치해도 식별할 수 있다는 것입니다.

CPU ID가 저장되어 있다는 걸 어디선가 읽었어요.방법을 찾을 수 없었습니다만, 매우 의심스럽습니다.MAC 주소를 사용하고 있는 경우도 있습니다.

방법을 찾으면 꼭 공유할게요.

요령:

1. 2개의 등록 페이지 작성:

   첫 번째 등록 페이지: 이메일 또는 보안 체크 없음(사용자 이름과 비밀번호만)

   두 번째 등록 페이지: 높은 보안 수준(이메일 검증 요구 및 보안 이미지 등)

2. 고객 만족과 쉬운 등록을 위해 기본 등록 페이지는 (첫 번째 등록 페이지)로 해야 하지만 (첫 번째 등록 페이지)에는 숨겨진 제한이 있습니다.IP 제한입니다.IP가 블록 페이지를 표시하지 않고 두 번째로 등록하려고 했을 경우(1시간 미만 등).(두 번째 등록 페이지)를 자동으로 표시할 수 있습니다.

3. (First Registration Page)에서 설정할 수 있습니다(예를 들어 1시간 또는 24시간 동안1개의 IP로부터의 2번의 시행을 차단합니다).또, 1시간 후에, 그 IP로부터의 액세스를 자동적으로 열 수 있습니다.

주의: (첫 번째 등록 페이지)와 (두 번째 등록 페이지)는 구분하여 사용할 수 없습니다.한 페이지만 만들어요.(예를 들어 register.php)를 사용하여 First PHP Style과 Second PHP Style을 전환할 수 있습니다.

언급URL : https://stackoverflow.com/questions/216542/how-do-i-uniquely-identify-computers-visiting-my-web-site