Ответ 1

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

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

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

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

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

Ответ 2

Введение

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

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

Даже если есть способы отследить компьютер без использования файлов cookie, всегда найдется способ обойти его и программное обеспечение, которое сделает это автоматически. Если вам действительно нужно что-то отслеживать на компьютере, вам нужно написать собственное приложение (Apple Store/Android Store/Windows Program/etc).

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

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 навсегда. Это данные, которые автоматически воссоздают себя, даже если пользователь удаляет свои куки или обновляет свой браузер. Тем не менее, пользователь не сможет удалить свои куки и кеш просмотра.

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

Юридическая

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

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

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

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

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

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

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

1. Данные должны быть зашифрованы/расшифрованы и подписаны/проверены, что создает накладные расходы процессора на клиенте (не так уж плохо) и на сервере (ба!).
2. Данные удаляются, когда пользователь удаляет свои куки и кеш. (это то, что я действительно хочу)
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: создан из файла cookie __utma. getCookie(__utma).uniqueid

Механизм

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

1. Удаляет историю посещенных веб-сайтов.
2. Удаляет куки и 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 оставался в браузере?

Этого можно добиться, используя заголовки HTTP, 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 (Very Hard). Объемные атаки не будут работать, потому что мы используем временную метку для генерации ключа шифрования/подписи, так что в основном это похоже на генерацию нового ключа для каждой сессии. Кроме того, мы шифруем случайные байты, поэтому о простой атаке по словарю также не может быть и речи.

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

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

Ответ 3

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

Ответ 4

Возможность использует флеш файлы cookie:

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

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

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

Ответ 5

Возможно, вам захочется попробовать установить уникальный идентификатор в evercookie (он будет работать с перекрестным браузером, см. их часто задаваемые вопросы): http://samy.pl/evercookie/

Существует также компания под названием ThreatMetrix, которая используется многими крупными компаниями для решения этой проблемы: http://threatmetrix.com/our-solutions/solutions-by-product/trustdefender-id/ Они довольно дороги, а некоторые из их других продуктов не очень хороши, но их идентификатор устройства хорошо работает.

Наконец, есть реализация jQuery с открытым исходным кодом идеи panopticlick: https://github.com/carlo/jquery-browser-fingerprint Сейчас он выглядит довольно испеченным, но его можно расширить.

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

Ответ 6

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

В статье также рассматриваются другие постоянные методы отслеживания, такие как evercookies, обновляющиеся HTTP и Flash файлы cookie и синхронизация файлов cookie.

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

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

Ответ 7

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

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

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

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

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

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

Ответ 8

Существуют недостатки как с подписями cookie, так и с не-cookie. Но если вы можете простить недостатки подхода печенья, вот идея.

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

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

Ответ 9

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

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

Ответ 10

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

Ответ 11

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

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

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

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

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

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

Ответ 12

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

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

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

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

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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

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

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

Ответ 15

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

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

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

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

Ответ 16

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

Ответ 17

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

Ответ 18

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

Ответ 19

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

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

Ответ 20

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

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

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

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

Ответ 21

Трюк:

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

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

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

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

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

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