что можно узнать о пользователе php
Что PHP может узнать о браузере посетителя?
О чем это?
Возможно ли узнать более детальную информацию о браузере посетителя кроме строки, содержащейся в $_SERVER[«HTTP_USER_AGENT»]: поддерживает ли яву, апплеты, таблицы стилей и фреймы? А может это вообще гуглобот зашел?
Предистория
Захотелось заказчику, чтобы при заходе на сайт отображался его любимый логотип с пробегающей по нему искоркой света… Уговорить отказаться от этой идеи человека я так и не смог, но в итоге мы решили, что радость эта будет отображаться только раз, и только при заходе на главную страницу. Если человек попал на сайт с поисковика, он сразу переходит на страницу. Если он руками вписывает адрес в браузер, он перенаправляется на страницу с анимацией. После успешного отображения в куки пишется маркер, и видео больше не грузится. Но… Если на сайт зайдет не человек, а поисковик, то писать себе куки он не будет. Поэтому он всегда будет натыкаться на страницу с анимацией, и в выдаче поисковиков мы себя так и не увидим. Да и зачем поисковику логотип компании видеть 🙂
Как можно узнать что-либо о браузере клиента
Проблема в итоге была решена методом поиска подстроки имен пауков нескольких известных поисковиков в переменной $_SERVER[«HTTP_USER_AGENT»]. Но перед этим я походил по ману и обнаружил интересную функцию get_browser(). Она умеет выдавать массив параметров браузера гостя нашего сайта, назначения половины которых, правда, я так и не понял 🙂 Единственная тонкость работы этой функции в том, что она требует наличия на хосте свежей версии файла browscap.ini, а также настройки php.ini. Очевидно что нашим ленивым (просьба не обижаться) админам влом постоянно обновлять этот файлик, так что на это обычно забивают и функция попросту недоступна. Проверить это можно, заглянув в phpinfo(), отыскав там диррективу browscap, и ничуть не удивившись что напротив нее гордо красуется надпись «no value», приступить к прочтению следующего параграфа.
Что же делать
if(ini_get(‘browscap’))
<
//неленивые админы попались
>
else
<
//используем нашу библиотеку
require_once(‘browscap.php’);
$bc = new Browscap(‘path/to/the/cache/dir’);
$browserInfo=$bc->getBrowser();
UPD. Полученные данные свидетельствуют лишь о поддержке браузером некоторой технологии, а не о ее доступности, так как файл browscap.ini это по сути база данных всех веб-клиентов, в которой по значению User-Agent браузера предоставляется информация о поддерживаемых этим браузером технологиях. Тоесть для современных браузеров при отключенных куках и яве соответствующие параметры все равно будут возвращать еденицу.
Куда применять эту функцию, надеюсь, каждый найдет для себя сам 🙂
Как в PHP узнать IP пользователя и определить его страну?
В этой статье рассмотрим, как в PHP можно узнать IP клиента и сервера, а также разберём как зная IP клиента определить его страну и город.
Как в PHP получить IP адрес посетителя сайта
Определение страны по ip с помощью Sypex Geo
Основные шаги по созданию php скрипта, с помощью которого можно будет определять страну по ip:
1. Скачаем Sypex Geo для PHP и базу данных стран. Sypex Geo распространяется по лицензии BSD, т.е. является абсолютно бесплатным.
2. Распакуем архивы и загрузим на сервер файлы «SxGeo.php» и «SxGeo.dat». В качестве примера, создадим на сервере папку SxGeo и загрузим эти файлы в неё.
3. Создадим свой скрипт, например, «get_country_code.php».
4. Вставим в этот файл следующий код:
5. Включим файл «get_country_code.php» в другие скрипты, в которых нужно реализовать выполнение кода в зависимости от принадлежности ip посетителя к той или иной стране.
Определение города по ip с помощью Sypex Geo
Для определения города, потребуется загрузить архив с базой данных городов для Sypex Geo, распаковать его и загрузить на сервер.
Скрипт в этом случае будет следующий:
Для автоматического обновления баз можно воспользоваться этим архивом. В этом архиве находится php скрипт. Этот скрипт необходимо настроить, т.е. указать в нём URL для скачивания базы и пути к файлам на сервере. После этого загрузить его на сервер и настроить его запуск по расписанию с помощью cron.
Определение страны и города по ip через сервис через сервис ipstack
Рассмотрим ещё один вариант определения в php местоположения по ip посетителя, но уже не через Sypex Geo, а с помощью сервиса ipstack.
Сервис ipstack имеет бесплатный план, который позволяет обрабатывать до 10000 запросов в месяц.
Для получения бесплатного плана нажимаем на кнопку «GET FREE API KEY» и переходим на страницу, на которой нужно заполнить регистрационную карточку.
После регистрации, на личной странице ipstack вам будет назначен «API Access Key», который нужно скопировать. Он нам потребуется при создании php скрипта.
Как в PHP получить IP адрес сервера
Узнать IP адрес сервера в PHP можно с помощью следующей инструкции:
Пример реализации определения локации в CMS MODX
В качестве примере рассмотрим, как в CMS MODX Revolution можно очень просто без сторонних сервисов осуществить определение страны посетителя. Разработаем решение на базе Sypex Geo.
1. Для этого сначала нужно загрузить Sypex Geo в проект:
Файл «SxGeo.php» – это основной скрипт, а «SxGeo.dat» – это база стран. Этих двух файлов достаточно для определения страны пользователя по его ip. Дополнительно в каталоге SxGeo ещё расположен файл «SxGeoCity.dat», данный файл в текущей реализации не нужен, он может потребовать, если в проекте потребуется определять не только страну пользователя, а ещё его регион и город.
2. Создадим сниппет, например «get_location.php». В качестве примера организуем это с помощью файлов. Для этого нужно чтобы был установлен pdoTools и в настройках включена опция «Использовать Fenom на страницах».
Код сниппета «get_location.php»:
Всё теперь чтобы написать логику достаточно использовать эту переменную.
Что именно идентифицирует посетителя сайта?
Изучая backend, столкнулся с такой проблемой недопонимания: есть сайт, сервер Nodejs (в принципе, какой угодно, но меня интересует именно Nodejs) и зашел на сайт посетитель. Не важно есть ли регистрация на сайте или нет — что именно идентифицирует посетителя?
В итоге, не прошу никакого кода (если это только не обязательно для наглядного примера). Прошу объяснить саму логику восприятия сервером посетителей. Как определить кто есть кто?
3 ответа 3
Перечислю все известные мне способы идентификации пользователя.
IP-адрес
Указываю этот способ потому, что он единственный, который невозможно подделать. Его можно позаимствовать у других (прокси, VPN, Tor, просто динамический IP), но это обычно сложнее, чем, например, почистить куки. Удалить IP-адрес, аналогично чистке cookies, нельзя: какой-нибудь обязательно будет. В связи с его относительной надёжностью (не всем не лень держать наготове сотни прокси-серверов для смены IP) его часто используют для усиления безопасности: например, ограничивают максимальное число запросов в секунду/минуту/час с одного IP. Однако разных людей, сидящих через один интернет, IP различить не даст, что противоречит условию вопроса, поэтому едем дальше.
Банальные логин и пароль
В HTTP-варианте суть такова:
при первом посещении сайта у клиента ничего нет и никакой дополнительной информации серверу не шлёт. Сервер отвечает ошибкой 401 Unauthorized и добавляет HTTP-заголовок WWW-Authenticate с информацией о способах входа (для простого логина-пароля это Basic realm=»default» )
сайт это всё проверяет и или отвечает нормально, или опять 401 и запрашиваем логин-пароль на новый
Этот Authorization: Basic YWRtaW46MTIzNDU2 шлём каждый раз во всех последующих запросах.
без HTTPS безопасность вообще никакая: логин-пароль по сути ходят по интернету в открытом виде (base64 не является шифрованием). Клиент тоже вынужден помнить у себя пароль в открытом виде, да и сервер тоже знает пароль (существуют схемы аутентификации, при которых сервер может и не знать пароль, но вопрос не об этом);
HTTP Basic Auth в браузерах работает только в пределах текущей сессии; после перезапуска браузера логин-пароль нужно вводить снова.
Случайная строка
Самый простой, самый сбалансированный в отношении «безопасность/удобство» и самый популярный способ идентификации. Самая распространённая в мире (наверно) кука PHPSESSID — это именно оно. Суть такова:
при первом посещении сайта у клиента ничего нет. Сайт замечает это, создаёт новую случайную строку (подлиннее, чтоб трудно было подобрать; символов 30 хотя бы) и вместе с обычным ответом на запрос тем или иным образом отправляет эту сгенерированную строку (Set-Cookie, редирект на специальную ссылку или просто в теле ответа, если это например JSON API)
клиент вместе с ответом получает эту строку и запоминает её где-нибудь (браузер сам хранит в cookies, SPA может положить её в localStorage и т.п.)
при последующих посещениях сайта клиент добавляет эту строку к своему запросу (cookies, HTTP-заголовок Authentication или просто GET-параметр в запрашиваемом адресе — на некоторых старых PHP-форумах до сих пор можно наблюдать id сессии прямо в адресной строке)
если нужно идентифицировать клиента более конкретно (вход по логину-паролю, например), сайт в своей базе данных после записывает, что такой-то случайной строке соответствует такой-то логин, а потом при последующих запросах считывает эту информацию из базы.
простота — сравнивать строки тривиально;
при смене IP-адреса (а на мобильниках это частое явление) идентификация не слетает;
реализация кнопочки «Разлогинить меня на всех устройствах» сводится к простому удалению всех записей в базе, а если для каждого устройства создавать отдельную строку, то можно разлогинивать устройства выборочно (некоторые сайты предоставляют такую возможность, например ВК).
генератор случайной строки должен быть действительно случайным (или не совсем случайным, но криптостойким, не uniqid() ), так как псевдослучайность злоумышленник может попытаться подобрать (например, подбор состояния генератора в PHP или Python, или подбор сессий, созданных черех uniqid(), в Invision Power Board). Ни в коем случае в качестве строки нельзя использовать хэш логина, хэш пароля, текущее время, одну-единственную заранее заготовленную строку и прочие неслучайные вещи, так как это сильно упрощает подбор. Как получить настоящую случайность, читайте в документации к вашему языку программирования. Или просто используйте готовую реализацию вроде session_start() в PHP;
дополнительная нагрузка на сервер. Чтобы узнать, какой именно пользователь прячется за случайной строкой, ему приходится обращаться к базе данных. Не проблема для подавляющего большинства сайтов, но для гигантов типа гугла уже проблема;
куки иногда баганутые: например, IE11 добавляет куки к поддоменам, даже когда его не просят (в Edge уже исправлено), что может привести к утечке данных на сторонние CDN, например. Поэтому следите за тем, как браузеры, для которых вы затачиваете сайт, манипулируют с куками. Ну и про HttpOnly не забывайте, чтобы нельзя было угнать куки через XSS (и про Secure, если сайт использует HTTPS).
Неслучайная, но защищённая строка (например, JWT)
Суть такова: нагло нарушаем вышеупомянутый запрет на неслучайные данные и пихаем в строку, например, ID пользователя и, опционально, имеющиеся права доступа (например, админ ли он), срок годности строки и какие-нибудь ещё данные. Но! Дополнительно к этой строке добавляем какой-нибудь хэш, который считается по данным плюс некой секретной строке, которую знает только сайт и никому не отдаёт. При запросе от клиента сайт, соответственно, проверяет, что хэш правильный. Это защищает от подбора и подделок: чтобы подделать данные, нужно пересчитать хэш, а злоумышленник, не зная секретной строки, этого сделать не сможет. (Секретная строка должна быть ОЧЕНЬ длинной, символов сто, чтоб вообще не подобрать, так как на ней вся безопасность.) (В JWT также вместо просто секретной строки можно применять RSA для подписи, что повышает безопасность, но расписывать все детали реализации не буду, и так длинно получилось)
меньшая нагрузка на сервер. Клиент уже сам прислал все нужные данные, серверу остаётся лишь посчитать хэш от этих данных и секретной строки и проверить, что он совпадает с присланным. В базу данных ходить не надо: секретная строка обычно лежит в какой-нибудь переменной поблизости, так что всё это делается быстро;
независимость от централизованной базы данных позволяет легко проверять аутентификацию на независимых и никак не связанных друг с другом микросервисах, в том числе географически разбросанных по миру, ведь им достаточно знать лишь секретную строку, которая меняется очень редко, для проверки присланного пользователем хэша, и не нужно связываться с другими микросервисами или с базой;
клиент сам может прочитать JWT и понять, кто он такой (если данные только защищать хэшем, а не шифровать);
при смене IP-адреса тоже не слетает.
реализация усложняется. Если делать всё самому, то можно накосячить и получить дырку в безопасности, поэтому лучше брать готовые реализации вроде того же JWT (впрочем, в них тоже иногда находят дырки, так что обязательно мониторим новости и почитываем Хабр);
кнопочку «Разлогинить меня на всех устройствах» сделать вообще нельзя. Чтобы пользовательская строка с данными стала недействительной, нужно или сменить секретную строку, или запомнить где-то в базе, что именно такая-то строка с такими-то данными стала недействительна. Но это всё довольно проблематично и сводит на нет все преимущества данного способа идентификации. Поэтому такие строки, как правило, делают короткоживущими: например, Google в своих API выдаёт JWT, действительный всего полчаса (информация о сроке годности хранится прямо в JWT и тоже защищается хэшем, в базу ходить не надо).
информация может протухнуть. Например, если записать в JWT, что пользователь является админом, а потом отобрать права админа, то сайт, опираясь на данные JWT, будет продолжать считать клиента админом, пока сам JWT не протухнет целиком. Можно брать информацию из базы, но тогда опять становится проще использовать случайную строку.
JWT и аналоги из-за того, что содержат всю необходимую информацию, обычно длинные; при большом количестве данных строка может, например, не влезть в cookies. Впрочем, если хранить только id пользователя, то это не проблема.
Суперкуки и прочий фингерпринтинг
Суть в использовании технологий не по назначению. У каждого браузера и каждой ОС есть свои особенности поведения, и по этим особенностям можно довольно точно идентифицировать, кто именно зашёл. Например, они рисуют текст немного по-разному, и по мелким отличиям в пикселях текста браузеры можно различать, или же на разных компьютерах будет немножко разный размер окна браузера, развёрнутого на весь экран (поэтому Tor Browser рекомендует не разворачивать его и блокирует сайтам доступ к canvas). Не буду расписывать всё во всех подробностях, оставлю ссылки для дальнейшего чтения:
точность не стопроцентная. Все айфоны довольно одинаковые, и отличить один айфон X от другого айфона X вряд ли получится (хотя это касается только фингерпринтинга, для суперкук попроще);
Аутентификация пользователя на сайте. Сессии и куки
Особенности работы протокола HTTP
Как вы узнали из прошлой главы, работа с веб-сайтами в интернете происходит по протоколу HTTP.
Это замечательный и простой протокол, который действует по схеме «запрос-ответ». То есть клиент (браузер) пользователя посылает на сервер запрос, состоящий, как правило, только из заголовков, а затем получает ответ в виде заголовков ответа и тела самого документа.
В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ».
Иными словами, сервер не «запоминает» клиентов; каждый запрос он обрабатывает с «чистого листа».
Для сервера нет никакой разницы: запросил один пользователь страницу десять раз или десять разных пользователей по разу. Для него все запросы одинаковые.
Чем это неудобно для нас?
Часто сайты должны уметь идентифицировать своих посетителей, чтобы сохранять и показывать им позже какую-либо информацию.
Например, интернет-магазины могут сохранять историю просмотров, чтобы рекомендовать потенциальным покупателям наиболее подходящие им товары. Или агрегатор новостей мог бы предложить пользователям выбирать только интересующие их рубрики.
К счастью, протокол HTTP, а также все браузеры предоставляют возможность сохранения информации о пользователе.
Cookies
Cookies (в дальнейшем просто «куки») — небольшие фрагменты данных, которые веб-сервер отправляет браузеру.
Браузер сохраняет их у себя, а при следующем посещении веб-страницы отправляет обратно. Благодаря этому, веб-сервер сможет узнать своего «старого» посетителя, идентифицировать его.
Пример
Задача очень проста: сохранять и показывать посетителю страницы, сколько раз он посетил наш сайт. Для этого будем сохранять количество посещений в отдельной куке, увеличивая значения на единицу при каждой загрузке страницы.
Как установить куки: функция setcookie
Являясь серверным языком программирования, PHP может управлять заголовками, которые отправляет сервер, а значит может устанавливать и читать куки.
Чтобы добавить новую куку, необходимо вначале определиться со следующими критериями:
Обратите внимание, что срок жизни указывается в относительной величине. В этом примере кука будет существовать ровно 30 дней с момента установки.
Как прочитать куки
Собираем всё вместе
Теперь, научившись устанавливать и читать куки, напишем полноценный сценарий, который будет считать и выводить количество посещений страницы пользователем:
Сессии
Мы уже умеем сохранять информацию для пользователя между посещениями страницы с помощью кук. Но зачем же нам ещё сессии, и для чего они нужны?
Сессии, они же сеансы, это, по сути, просто удобная обёртка над куками. Они также позволяют хранить данные, релевантные пользователю, но с некоторыми отличиями и ограничениями:
Как устроены сессии
Благодаря существованию сессий в PHP, мы можем сохранять любые данные так же просто, как присваивать их переменным. Но, в отличие от переменных, эти данные будут сохраняться для пользователя между запросами в пределах сеанса.
Перепишем сценарий для подсчета посещений, но теперь используем сессии:
Аутентификация
Представим интернет-магазин. Все его страницы можно разделить на две половины: публичные и приватные.
К публичным относятся страницы каталога, информации о товаре, условия доставки и так далее. К приватным — корзина покупок, история заказов.
Совершенно очевидно, что корзина покупок у каждого покупателя должна быть своя, а иметь к ней доступ должен только сам владелец и никто больше.
Процедура проверки возможности доступа пользователя к определенной части сайта и называется аутентификацией.
Весь процесс аутентификации всегда состоит из нескольких шагов:
Ещё немного терминологии
Следует различать два термина: аутентификация и авторизация.
Аутентификация — проверка подлинности предоставленного пользователем идентификатора (пара логин-пароль).
Авторизация — процесс проверки и предоставления прав пользователю на выполнение определённого действия.
В примере с интернет-магазином аутентификация выполняется, когда пользователь заполняет форму входа и попадает в свой личный кабинет. Сценарий, обрабатывающий форму, лишь проверяет, что такой пользователь существует, и его пароль совпадает.
Авторизация включается в работу, когда пользователь выполняет какое-нибудь действие. Например, удаляет товар из своей корзины. Во время этого действия сценарий должен проверить принадлежность товара к корзине этого пользователя. Без такой проверки пользователь мог бы удалить товар из чужой корзины.
Логика авторизации намного сложнее, чем простая проверка совпадения почты и пароля при входе на сайт. В авторизацию могут также входить следующие понятия: группы пользователей, виды действий, ресурсы, иерархия ролей и действий. Этой теме можно посвятить отдельную главу. Мы не рассматриваем авторизацию в рамках этого учебника, потому что эта тема выходит за рамки «базовой».
Регистрация на сайте
Перед тем, как мы начнем добавлять аутентификацию на своем сайте, придётся добавить форму для регистрации нового аккаунта.
Аккаунт — это учётная запись пользователя.
Чтобы завести аккаунт, требуется пройти регистрацию — это заполнение специальной формы, где пользователь указывает свою почту, пароль, и, возможно, дополнительную информацию.
После регистрации все данные из формы сохраняются в базе данных как есть. Но хранению паролей нужно уделить особое внимание.
Хранение паролей
Пароль пользователя — это секретный набор символов, который используется в дальнейшем в ходе аутентификации. Зная пароль пользователя, злоумышленник может войти на сайт под его именем. По этой причине пароль нельзя хранить в базе в открытом виде. Ведь если информацию из БД сайта украдут, то данные всех пользователей станут скомпрометированными.
Вместо самого пароля, в базе будут храниться их отпечатки — хэши.
Что такое хеширование
Отпечаток (хэш) — это результат работы функции хэширования, которая вернёт для любого значения строку фиксированной длины.
Используя специальный математический алгоритм, такая функция умеет преобразовывать любую переданную информацию к строке фиксированной длины (например, 32 или 64 символа). Причём любому массиву информации, будь это все статьи из Википедии, или одно слово, всегда будет соответствовать уникальный отпечаток. Повторный вызов функции для одного и того же исходника всегда возвращает один и тот же хэш.
Обратная операция (получить из отпечатка оригинал) невозможна.
Возьмём простой пример. У нас есть информация, для которой мы хотим получить отпечаток. Пусть такой информацией будет следующая строка:
Результат обработки этой строки хэширующей функцией SHA-1 будет таким:
6b3cb0df50fe814dee886b4e1c747dda6ce88b37
Хэширующие функции часто используются для контроля целостности информации при передачи по сети. Например, чтобы убедиться в том, что загруженный файл не был повреждён, достаточно получить его хэш и сравнить данный хэш с опубликованным на сайте. Если в файле поменялся хоть один байт, то эти отпечатки будут совершенно разными.
Нам же функции хэширования помогут для сравнения паролей.
Реализация регистрации пользователя
Вернёмся к форме регистрации.
Выше говорилось, что вместо пароля лучше хранить его отпечаток. Для получения отпечатка существуют множество хэшируюших функций. К счастью, нам не надо разбираться в их многообразии, потому что в PHP есть стандартная функция, которая делает ровно то, что нужно.
Вот пример как из пароля получить отпечаток, пригодный для хранения в базе:
Проверка пароля при входе на сайт
Использование сессии для контроля доступа
Сессии чаще всего используются для хранения информации о залогиненном пользователе. Принцип работы здесь очень простой: внутри сценария, ответственного за обработку формы входа, открывается новая сессия, куда записывается информация о вошедшем пользователе. Такой информацией может быть ассоциативный массив со всеми значениями из соответствующей записи из БД.
Затем добавим код, проверяющий существование сессии в сценарии, которые должны быть закрыты от анонимных пользователей. Если сессия пуста, значит данный пользователь не выполнял вход на сайт, и доступа к данной странице он не имеет.
В этом случае можно вернуть код ответа 403 и показать сообщение об ошибке, либо принудительно выполнить переадресацию на главную страницу.
Выход с сайта
Пользователи онлайн
Принцип реализации
На многих сайтах есть необходимость определять, какие пользователи в данный момент находятся на связи. Например, это используется в социальных сетях. Эта функция реализуется так: каждый пользователь регулярно отправляет на сервер информацию о том, что он в сети. Время этого сообщения записывается в БД. Если пользователь отправлял это сообщение совсем недавно, то считается что он в сети. Таким образом, реализация данной функции состоит из двух частей:
Для реализации этой функции в таблице с пользователями должно быть поле, куда записывается время обновления информации.
Обновление информации
Это действие можно выполнить двумя способами. Простой вариант заключается в том, что информация обновляется при переходе по страницам. Но этот способ имеет недостаток. Пользователь может долго находиться на одной странице и не переходить по другим страницам. Тогда информация о том, что он на связи, не обновляестя и будет указано, что он вышел с сайта. А если увеличить время, в течении которого пользователь считается онлайн, то получится противоположная ситуация. Пользователь уже вышел с сайта, но ещё долго считается, что он в сети. Оптимально подобрать время достаточно сложно.
Более сложный способ состоит в использовании AJAX. На каждой странице сайта должен быть скрипт, который регулярно обновляет информацию в БД. При этом Вы точно знаете, через какие промежутки времени происходит обновление информации. Мы рассмотрим оба способа.
Страницы сайта должны быть такие:
Для второго способа Вы должны зать технологию AJAX. Вместо предложенного выше кода на каждой странице сайта должет быть скрипт, регулярно отправляющий запросы на сервер. Он выглядит так:
На сервере запускается скрипт infonline.php. Он точно такой же, как на странице в первом примере. Только в нём не должно быть HTML тегов.
Вывод пользователей онлайн
Коприрование материалов сайта возможно только с согласия администрации