Введение

Я не знаю, существует ли или когда-либо будет способ однозначно идентифицировать машины, используя только браузер. Основные причины:

• Вам нужно будет сохранить данные на компьютере пользователя. Эти данные могут быть удалены пользователем в любое время. Если у вас нет способа воссоздать эти данные, уникальные для каждой машины, тогда вы застряли.
• Проверка. Вам необходимо принять меры против спуфинга, перехвата сеанса и т. Д.

Даже если есть способы отслеживать компьютер без использования файлов 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. Для вошедших в систему пользователей вы всегда можете сгенерировать один и тот же идентификатор сеанса из пользователей username / password / email.
2. Вы по-прежнему можете отслеживать гостевых пользователей с помощью sessionID.
3. Даже если несколько человек используют один и тот же компьютер (например, интернет-кафе), вы можете отслеживать их по отдельности, если они войдут в систему.

Недостатки отслеживания на основе сеанса:

1. Сеансы основаны на браузере, а не на компьютере. Если пользователь использует 2 разных браузера, это приведет к 2 различным сеансам. Если это проблема, вы можете перестать читать здесь.
2. Сеансы истекают, если пользователь не вошел в систему. Если пользователь не вошел в систему, он будет использовать гостевой сеанс, который будет аннулирован, если пользователь удалит файлы cookie и кеш браузера.

Выполнение

Есть много способов реализовать это. Я не думаю, что смогу охватить их все. Я просто перечислю свои любимые, что сделало бы этот ответ самоуверенным. Имейте это в виду.

Основы

Я буду отслеживать сеанс с помощью так называемого файла cookie навсегда. Это данные, которые автоматически воссоздаются, даже если пользователь удалит свои файлы cookie или обновит свой браузер. Однако он не сможет выжить, если пользователь удалит как свои файлы cookie, так и кеш просмотра.

Для реализации этого я буду использовать механизм кеширования браузеров (RFC), WebStorage API ( MDN) и файлы cookie браузера (RFC, Google Analytics).

Юридический

Чтобы использовать идентификаторы отслеживания, вам необходимо добавить их как в свою политику конфиденциальности, так и в условия использования, желательно в подзаголовке Отслеживание. Мы будем использовать следующие ключи как на document.cookie, так и на window.localStorage:

• _ga: данные Google Analytics.
• __utma: файл cookie отслеживания Google Analytics.
• sid: SessionID

Убедитесь, что вы разместили ссылки на свою Политику конфиденциальности и условия использования на всех страницах, на которых используется отслеживание.

Где мне хранить данные моего сеанса?

Вы можете хранить данные сеанса в базе данных вашего веб-сайта или на компьютере пользователя. Поскольку я обычно работаю на небольших сайтах (допускается более 10 тысяч непрерывных подключений), которые используют сторонние приложения (Google Analytics / Clicky и т. Д.), Мне лучше всего хранить данные на компьютере клиента. Это дает следующие преимущества:

1. Нет поиска в базе данных / накладных расходов / нагрузки / задержки / места / и т. Д.
2. Пользователь может удалить свои данные, когда захочет, без необходимости писать мне надоедливые электронные письма.

и недостатки:

1. Данные должны быть зашифрованы / дешифрованы и подписаны / проверены, что создает накладные расходы на ЦП на клиенте (не так уж и плохо) и на сервере (да!).
2. Данные удаляются, когда пользователь удаляет свои файлы cookie и кеш. (это то, что я действительно хочу)
3. Данные недоступны для аналитики, когда пользователи отключены. (аналитика только для просматриваемых в данный момент пользователей)

UUIDS

• BrowserID: уникальный идентификатор, созданный на основе строки пользовательского агента браузера. Browser|BrowserVersion|OS|OSVersion|Processor|MozzilaMajorVersion|GeckoMajorVersion
• ComputerID: создается на основе IP-адреса пользователя и ключа сеанса HTTPS. getISP(requestIP)|getHTTPSClientKey()
• FingerPrintID: снятие отпечатков пальцев на основе JavaScript на основе измененного fingerprint.js. FingerPrint.get()
• SessionID: случайный ключ, генерируемый при первом посещении сайта пользователем. BrowserID|ComputerID|randombytes(256)
• GoogleID: создается из __utma файла cookie. getCookie(__utma).uniqueid

Механизм

На днях я смотрел шоу Венди Уильямс со своей девушкой и был в полном ужасе, когда ведущий посоветовал своим зрителям удалить историю их браузера не реже одного раза в месяц. Удаление истории браузера обычно имеет следующие эффекты:

1. Удаляет историю посещенных сайтов.
2. Удаляет файлы cookie и window.localStorage (оу, человек).

Большинство современных браузеров делают эту опцию легко доступной, но не бойтесь, друзья. Ибо выход есть. В браузере есть механизм кеширования для хранения скриптов / изображений и прочего. Обычно, даже если мы удаляем нашу историю, этот кеш браузера все равно остается. Все, что нам нужно, это способ хранить здесь наши данные. Есть 2 способа сделать это. Лучше использовать изображение SVG и хранить наши данные внутри его тегов. Таким образом, данные могут быть извлечены, даже если JavaScript отключен с помощью flash. Однако, поскольку это немного сложно, я продемонстрирую другой подход, использующий 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(getTimestamp($sid) + getBrowserID($sid) + getComputerID($sid) + decrypt(getRandomBytes($sid), hk), getSignature($sid), $hk) ) return false;

return true; 

Теперь, чтобы атака Хаксора сработала, они должны:

1. Есть такой же ComputerID. Это означает, что у них должен быть тот же провайдер Интернет-услуг, что и у жертвы (Tricky). Это даст нашей жертве возможность подать в суд в своей стране. Haxor также должен получить сеансовый ключ HTTPS от жертвы (Hard).
2. Есть такой же BrowserID. Кто угодно может подделать строку User-Agent (раздражает).
3. Уметь создавать свои подделки SessionID (Очень сложно). Объемные атаки не будут работать, потому что мы используем временную метку для генерации ключа шифрования / подписи, так что в основном это похоже на создание нового ключа для каждого сеанса. Кроме того, мы шифруем случайные байты, поэтому простая атака по словарю также исключена.

Мы можем улучшить проверку, пересылая GoogleID и FingerprintID (через ajax или скрытые поля) и сопоставляя их.

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

Эти люди разработали метод снятия отпечатков пальцев для распознавания пользователя с высокой степенью точности:

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

Мы изучаем степень, в которой современные веб-браузеры подвержены «отпечатку пальца устройства» с помощью информации о версии и конфигурации, которую они будут передавать на веб-сайты по запросу. Мы реализовали один из возможных алгоритмов снятия отпечатков пальцев и собрали эти отпечатки из большой выборки браузеров, которые посетили нашу тестовую сторону, Panopticlick.eff.org. Мы наблюдаем, что распределение нашего отпечатка пальца содержит не менее 18,1 бит энтропии, а это означает, что если мы выберем браузер наугад, в лучшем случае мы ожидаем, что только один из 286 777 других браузеров поделится своим отпечатком. Среди браузеров, поддерживающих Flash или Java, ситуация еще хуже: средний браузер содержит не менее 18,8 бит идентифицирующей информации. 94,2% браузеров с Flash или Java были уникальными в нашей выборке.

Наблюдая за вернувшимися посетителями, мы оцениваем, насколько быстро отпечатки браузера могут меняться со временем. В нашей выборке отпечатки пальцев менялись довольно быстро, но даже простая эвристика обычно позволяла угадать, когда отпечаток был «обновленной» версией ранее наблюдаемого отпечатка пальца браузера, с 99,1% правильных догадок и ложноположительным показателем только 0,86%. .

Мы обсуждаем, какие угрозы конфиденциальности создают в браузере на практике, и какие контрмеры могут быть подходящими для его предотвращения. Существует компромисс между защитой от отпечатков пальцев и некоторыми видами отладки, которая в текущих браузерах сильно влияет на конфиденциальность. Как это ни парадоксально, технологии защиты конфиденциальности от снятия отпечатков пальцев могут быть обречены на провал, если они не используются достаточным количеством людей; мы показываем, что некоторые меры по обеспечению конфиденциальности в настоящее время становятся жертвой этого парадокса, а другие - нет ...

Невозможно идентифицировать компьютеры, обращающиеся к веб-сайту, без сотрудничества с их владельцами. Однако, если они позволят вам, вы можете сохранить файл cookie, чтобы идентифицировать машину, когда она снова посетит ваш сайт. Ключ в том, что посетитель все контролирует; они могут удалить cookie и появиться как новый посетитель в любое время, когда захотят.

Есть возможность использовать flash cookie:

• Повсеместная доступность (95 процентов посетителей, вероятно, будут иметь flash)
• Вы можете хранить больше данных в одном файле cookie (до 100 КБ)
• Совместно используется в браузерах, поэтому с большей вероятностью можно будет однозначно идентифицировать машину.
• Очистка файлов cookie браузера не приводит к удалению флеш-файлов cookie.

Вам нужно будет создать небольшой (скрытый) флэш-фильм, чтобы читать и писать их.

Какой бы маршрут вы ни выбрали, убедитесь, что ваши пользователи соглашаются на отслеживание, иначе вы вторгнетесь в их конфиденциальность и станете одним из плохих парней.

Вы можете попробовать установить уникальный идентификатор в evercookie (он будет работать в разных браузерах, см. Их ответы на часто задаваемые вопросы): 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, повторное создание файлов cookie http и Flash и синхронизация файлов cookie.

Подробнее о снятии отпечатков пальцев на холсте:

• Pixel Perfect: отпечатки пальцев на холсте в HTML5
• https://en.wikipedia.org/wiki/Canvas_fingerprinting

Есть лишь небольшой объем информации, который вы можете получить через HTTP-соединение.

1. IP - Но, как говорили другие, это не исправлено для многих, если не для большинства пользователей Интернета, из-за политик динамического распределения их провайдеров.

2. Useragent String - Почти все браузеры при каждом запросе отправляют тип своего браузера. Однако сегодня это может быть установлено пользователем во многих браузерах.

3. Сбор полей запроса. С каждым запросом отправляются и другие поля, например, поддерживаемые кодировки и т. Д. Они, если они используются в совокупности, могут помочь идентифицировать машину пользователя, но, опять же, зависят от браузера и могут быть изменены.

4. Файлы cookie - установка файлов cookie - это еще один способ идентифицировать машину или, в частности, браузер на машине, но, как говорили другие, они могут быть удалены или отключены пользователями и применимы только в браузере, а не в машина.

Итак, правильный ответ заключается в том, что вы не можете добиться того, что вы бы жили, только с помощью протоколов HTTP поверх IP. Однако, используя комбинацию файлов cookie, а также IP-адреса и полей в HTTP-запросе, у вас есть хороший шанс предположить, что это за машина. Пользователи, как правило, используют только один браузер и часто с одной машины, поэтому это может быть достаточно надежным, но это будет зависеть от аудитории ... технари с большей вероятностью возятся с этим и используют больше машин / браузеров. Кроме того, это может быть даже связано с некоторой попыткой определения местоположения IP-адреса и использования этих данных. Но в любом случае не существует решения, которое было бы всегда верным.

Есть недостатки как у файлов cookie, так и у подходов без файлов cookie. Но если вы можете простить недостатки подхода с использованием файлов cookie, вот вам идея.

Если вы уже используете Google Analytics на своем сайте, вам не нужно писать код для самостоятельного отслеживания уникальных пользователей. Google Analytics делает это за вас с помощью значения __utma cookie, как описано в документации Google. И, повторно используя это значение, вы не создаете дополнительную полезную нагрузку cookie, что дает преимущества с точки зрения эффективности при запросах страниц.

И вы могли бы достаточно легко написать код для доступа к этому значению или использовать функцию этого скрипта getUniqueId() .

Как и в случае с предыдущими решениями, файлы cookie - хороший метод, однако имейте в виду, что они идентифицируют браузеры. Если бы я посетил веб-сайт в Firefox, а затем в Internet Explorer, файлы cookie для обеих попыток сохранялись бы отдельно. Некоторые пользователи также отключают файлы cookie (но больше людей отключают JavaScript).

Еще один способ рассмотреть - это I.P. и идентификация имени хоста (имейте в виду, что они могут различаться для пользователей с коммутируемым / нестатическим IP-адресом, AOL также использует общие IP-адреса). Однако, поскольку это только идентифицирует сети, это может не работать так же хорошо, как файлы cookie.

Помимо предложений по использованию файлов cookie, единственный полный набор идентифицирующих атрибутов, доступных для опроса, содержится в заголовке HTTP-запроса. Таким образом, можно использовать некоторое их подмножество для создания псевдо-уникального идентификатора для пользовательского агента (то есть браузера). Кроме того, большая часть этой информации, возможно, уже по умолчанию заносится в так называемый «журнал доступа» программного обеспечения вашего веб-сервера, а если нет, то ее можно легко настроить для этого. Затем можно разработать средство, которое просто сканирует содержимое этого журнала, создавая отпечатки пальцев для каждого запроса, состоящего, например, из IP-адреса, строки пользовательского агента и т. Д. Чем больше данных доступно, даже включая содержание конкретных файлов cookie повышает уникальность этого отпечатка пальца. Хотя, как уже заявляли многие другие, протокол HTTP не делает это на 100% надежным - в лучшем случае это может быть лишь довольно хорошим показателем.

Когда я использую компьютер, который никогда не посещал мой веб-сайт онлайн-банкинга, меня просят провести дополнительную аутентификацию. затем, если я вернусь во второй раз на сайт онлайн-банкинга, меня не спросят о дополнительной аутентификации ... Я удалил все файлы cookie в IE и повторно зашел на свой сайт онлайн-банкинга, полностью ожидая, что мне снова зададут вопросы аутентификации. к моему удивлению, меня не спросили. Разве это не наводит на мысль, что банк выполняет какую-то маркировку ПК, не использующую файлы cookie?

Это довольно распространенный тип аутентификации, используемый банками.

Допустим, вы заходите на сайт своего банка через example-isp.com. При первом посещении вам будет предложено ввести пароль, а также пройти дополнительную аутентификацию. Как только вы прошли, банк знает, что пользователь thatisvaliant прошел аутентификацию для доступа к сайту через example-isp.com.

В будущем он не будет запрашивать дополнительную аутентификацию (помимо вашего пароля), когда вы заходите на сайт через example-isp.com. Если вы попытаетесь получить доступ к банку через another-isp.com, банк снова выполнит ту же процедуру.

Подводя итог, банк идентифицирует вашего интернет-провайдера и / или сетевой блок на основе вашего IP-адреса. Очевидно, что не каждый пользователь вашего интернет-провайдера - это вы, поэтому банк по-прежнему запрашивает ваш пароль.

Случалось ли вам когда-нибудь звонить в компанию по выпуску кредитных карт, чтобы убедиться, что все в порядке, когда вы используете кредитную карту в другой стране? Та же концепция.

На самом деле то, что вы хотите сделать, невозможно, потому что протоколы этого не позволяют. Если бы статические IP-адреса использовались повсеместно, вы могли бы это сделать. Их нет, поэтому вы не можете.

Если вы действительно хотите идентифицировать людей, попросите их войти в систему.

Поскольку они, вероятно, будут переходить на разные страницы вашего веб-сайта, вам нужен способ отслеживать их перемещение.

Пока они вошли в систему, и вы отслеживаете их сеанс на своем сайте с помощью файлов cookie / параметров ссылок / маяков / чего угодно, вы можете быть уверены, что они используют один и тот же компьютер в течение этого времени.

В конечном счете, неправильно говорить, что это говорит вам, какой компьютер они используют, если ваши пользователи не используют вашу собственную локальную сеть и не имеют статических IP-адресов.

Если то, что вы хотите сделать, осуществляется при сотрудничестве пользователей, и для каждого файла cookie используется только один пользователь, и они используют один веб-браузер, просто используйте файл cookie.

Поскольку я хочу, чтобы решение работало на всех машинах и во всех браузерах (в разумных пределах), я пытаюсь создать решение с использованием javascript.

Разве это не веская причина не использовать javascript?

Как уже говорили другие, файлы cookie, вероятно, ваш лучший вариант - просто помните об ограничениях.

Вы можете использовать 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, поэтому, даже если их отпечаток пальца мутирует, вы все равно можете отслеживать их.

Файлы cookie не будут полезны для определения уникальных посетителей. Пользователь может очистить файлы cookie и обновить сайт - тогда он снова будет классифицирован как новый пользователь.

Я думаю, что лучший способ сделать это - реализовать решение на стороне сервера (так как вам нужно будет где-то хранить ваши данные). В зависимости от сложности ваших потребностей в таких данных вам нужно будет определить, что считается уникальным посещением. Разумным методом было бы позволить IP-адресу вернуться на следующий день и получить уникальное посещение. Несколько посещений с одного IP-адреса за один день не считаются уникальными.

Например, с помощью PHP легко получить IP-адрес посетителя и сохранить его в текстовом файле (или в базе данных sql).

Решение на стороне сервера будет работать на всех машинах, потому что вы собираетесь отслеживать пользователя, когда он впервые загружает ваш сайт. Не используйте javascript, поскольку он предназначен для написания сценариев на стороне клиента, к тому же пользователь мог отключить его в любом случае.

Надеюсь, это поможет.

Я предполагаю, что вердикт таков: я не могу программно однозначно идентифицировать компьютер, который посещает мой веб-сайт.

У меня следующий вопрос. Когда я использую компьютер, который никогда не посещал мой веб-сайт онлайн-банкинга, меня просят провести дополнительную аутентификацию. тогда, если я вернусь во второй раз на сайт онлайн-банкинга, мне не нужно будет запрашивать дополнительную аутентификацию. читая ответы на мой вопрос, я решил, что это должен быть файл cookie. поэтому я удалил все файлы cookie в IE и повторно зашел на свой сайт онлайн-банкинга, ожидая, что мне снова зададут вопросы для аутентификации. к моему удивлению, меня не спросили. Разве это не наводит на мысль, что банк выполняет какую-то маркировку ПК, не использующую файлы cookie?

кроме того, после долгих поисков сегодня я нашел следующую компанию, которая утверждает, что продает решение, которое однозначно идентифицирует машины, которые посещают веб-сайт. http://www.the41.com/products.asp.

Я ценю всю хорошую информацию, если вы могли бы уточнить эту противоречивую информацию, которую я обнаружил, я был бы очень признателен.

Я бы сделал это, используя комбинацию файлов cookie и flash cookie. Создайте GUID и сохраните его в файле cookie. Если cookie не существует, попробуйте прочитать его из flash cookie. Если он по-прежнему не найден, создайте его и запишите во флеш-куки. Таким образом, вы можете использовать один и тот же GUID в разных браузерах.

Я думаю, что файлы cookie могут быть тем, что вы ищете; именно так большинство веб-сайтов однозначно идентифицируют посетителей.

Предполагая, что вы не хотите, чтобы пользователь контролировал ситуацию, вы не можете. Интернет так не работает, лучшее, на что вы можете надеяться, - это эвристика.

Если это вариант заставить вашего посетителя установить какое-то программное обеспечение и использовать TCPA, вы можете что-то сделать.

Мой пост может не быть решением, но я могу привести пример, в котором эта функция была реализована.

Если вы впервые посещаете страницу регистрации www.supertorrents.org со своего компьютера, ничего страшного. Но если вы обновите страницу или откроете ее снова, это определит, что вы ранее посещали эту страницу. Настоящая красота заключается в том, что она распознается, даже если вы переустанавливаете Windows или другую ОС.

Я где-то читал, что они хранят идентификатор процессора. Хотя я не мог найти, как они это делают, я серьезно в этом сомневаюсь, и они могут использовать для этого MAC-адрес.

Я обязательно поделюсь, если найду как это сделать.

Я буду предлагать свои идеи, начиная от более простых к более сложным. Во всем вышеперечисленном вы можете создавать сеансы, и проблема по существу переводится, чтобы сопоставить сеанс с запросом.

a) (сложность: легко) использовать клиентское оборудование для явного хранения идентификатора сеанса / хэша какого-либо типа (есть некоторые проблемы с конфиденциальностью / безопасностью, поэтому убедитесь, что вы хешируете все, что храните), решения включают:

• хранение файлов cookie
• хранилище браузера / webDB / (более экзотические браузерные решения)
• расширения с разрешением хранить вещи в файлах.

Вышеупомянутое страдает от того факта, что пользователь может просто очистить свой кеш, если он не хочет.

б) (сложность: средняя) Аутентификация на основе входа в систему. Большинство современных веб-фреймворков предоставляют такое решение, основная идея заключается в том, что вы позволяете пользователю добровольно идентифицировать себя, что довольно просто, но добавляет сложности в архитектуру.

Вышеупомянутое страдает дополнительной сложностью и делает по существу закрытый контент.

c) (сложность: жестко -R & D) Идентификация на основе метаданных, (IP-адрес браузера / язык / браузер / и другие инвазивные материалы, поэтому убедитесь, что вы сообщили своим пользователям, иначе вас могут подать в суд) неидеальное решение может стать более сложным (a пользователь печатает с определенной частотой или использует мышь с определенными шаблонами - вы даже применяете решения ML). Заявленные решения

Самый мощный, поскольку пользователь, даже не желая явно, может быть идентифицирован. Это прямое вторжение в частную жизнь (см. GDPR) и не идеально, например. ip можно поменять.

Уловка:

1. Создайте 2 страницы регистрации:

   Первая страница регистрации: без электронной почты или проверки безопасности (только с именем пользователя и паролем)

   Вторая страница регистрации: с высоким уровнем безопасности (запрос подтверждения электронной почты, изображение безопасности и т. д.)

2. Для удобства клиентов и упрощения регистрации страницей регистрации по умолчанию должна быть (Первая страница регистрации), но на (Первая страница регистрации) есть скрытое ограничение. Это ограничение IP. Если IP-адрес попытался зарегистрироваться во второй раз (например, менее 1 часа) вместо отображения страницы блокировки. вы можете автоматически отображать (вторую страницу регистрации).

3. на (Первая страница регистрации) вы можете установить (например: заблокировать 2 попытки с 1 IP всего на 1 час или 24 часа), и через (например) 1 час вы можете открыть доступ с этого ip автоматически

Обратите внимание: (Первая страница регистрации) и (Вторая страница регистрации) не должны находиться на отдельных страницах. вы делаете всего 1 страницу. (например: register.php) и сделайте умным переключение между первым стилем PHP и вторым стилем PHP.