Определение города и региона посетителя сайта с использованием PHP библиотеки nikolaevevgeGeoIP

Абдуллин Руслан

Рубрика:Полезное

Определение города и региона посетителя сайта

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

А также вы узнаете, какие есть достоинства у этой библиотеки.

На момент написания статьи библиотека работала только с CMS Joomla, WordPress и Bitrix и не была предназначена для работы в других системах. Поэтому, если Вы планируете использовать geo-библиотеку для других платформ, рекомендую пройти на официальную страницу библиотеки и проверить, не появилось ли в ней функционала для связи с базой данных, который позволил бы её использовать для Вашей платформы (исходя из диалога с автором планы разработать такой функционал есть). Вот ссылка на официальную страницу, с которой Вы можете скачать код библиотеки.

Мини инструкция по работе с библиотекой nikolaevevgeGeoIP

Итак, если CMS Вашего сайта, на котором Вы собираетесь работать с geo-данными, одна из указанных выше, то для получения гео-информации об IP адресе следуйте инструкции:

для начала работы Вам необходимо скачать файл библиотеки, и разместить его у себя на хостинге (предлагаю назвать его стандартным образом — nikolaevevgegeoip.php).
Затем в нужном Вам месте кода подключите данный файл с помощью вызова require_once (″adres-faila-biblioteki.php″).
После чего вызовите метод библиотеки nikolaevevgeGeoIp::get (). В данный метод в качестве единственного параметра Вы можете передать строкой IP-адрес, для которого Вы планируете получить информацию. Вы можете не передавать параметр, тогда информация будет предоставлена для IP-адреса посетителя, который обратился к Вашему сайту (то есть IP адрес, полученный из переменной $_SERVER["REMOTE_ADDR"]).

Обращаю внимание, если Вы, к примеру, работаете с библиотекой из какого-либо файла, предназначенного для Ajax взаимодействия с сайтом, то Вам совершенно не обязательно явным образом подключать файлы фреймворка Вашей CMS, библиотека сделает это самостоятельно. Причём, если файлы фреймворка CMS подключены, это также не приведёт к ошибке или повторному их подключению, то есть библиотека умеет определять CMS, используемую на данном виртуальном хосте, а также проверять подключение необходимых файлов. В результате вызова указанного метода информация будет получена оптимальным образом, по алгоритмам, о которых можно прочитать в разделе, посвященном истории развития библиотеки.

Полученный массив с geo-данными будет содержать следующую информацию (по крайней мере на момент написания стати это было именно так):

minipinstack – IP, с которого начинается стек адресов (строка, содержащая 4 числа, разделённая точками);
maxipinstack – IP, которым заканчивается стек адресов;
country — код страны (например RU);
region — название региона на русском языке, например «Ивановская область»;
regioncode — код региона, например «RU-IVA»;
city — название города на русском языке, например «Иваново».

Ещё раз приведу программный код на языке PHP, с помощью которого можно проверить работу библиотеки:
1
2
3
require_once("nikolaevevgegeoip.php"); 
$geoDataAr = nikolaevevgeGeoIp::get("88.85.172.134"); 
var_dump($geoDataAr);//Возвращает гео-информацию для указанного IP-адреса
require_once("nikolaevevgegeoip.php"); $geoDataAr = nikolaevevgeGeoIp::get("88.85.172.134"); var_dump($geoDataAr);//Возвращает гео-информацию для указанного IP-адреса

Преимущества использования библиотеки nikolaevevgeGeoIP

Возможность единообразного использования на CMS WordPress, Joomla и Bitrix (в будущем возможно расширение платформ)
Не требует каких-либо настроек, библиотека самостоятельно распознаёт Вашу CMS и создаёт необходимые таблицы в базе данных, в которых хранится кеш гео-запросов. Вы тем не менее можете настроить название таблицы для хранения данных, а также время обновления информации, а можете оставить настройки по умолчанию.
Вам не потребуется следить за актуальностью гео-базы, библиотека делает запросы к API-серверу для получения актуальных данных, и сохраняет её в базе Вашего сайта на указанный период времени.
Оптимально работает с повторными запросами, если Вы запросите информацию об одном и том же IP адресе в процессе выполнения скрипта, то это не приведёт к повторному запросу информации по API, а также повторному запросу к базе данных.
Предоставляет аналогичную популярным библиотекам гео-информацию: название города, название региона, код страны, код региона, временную зону к которой относится IP адрес.

История создания библиотеки nikolaevevgeGeoIP

Представляю Вашему вниманию историю создания и развития geo-библиотеки nikolaevevgeGeoIP на основания переписки с автором библиотеки. Библиотека может быть использована для определения региона и города посетителя сайта по его IP-адресу.

Сразу же напишу, что на момент публикации статьи данная библиотека не являлась самой популярной. При этом несмотря на ещё сравнительно недавнюю дату начала разработки (согласно официальному источнику это май 2019 года) рекомендацию на использование библиотеки иногда можно увидеть на форумах и прочих сообществах программистов. И это не спроста — у библиотеки действительно есть некоторые удобные преимущества, в том числе за которые стоит рассмотреть её для решения задачи определения города и региона посетителей Вашего сайта.

О том, что это за преимущества, я написал в разделе выше, а ниже по тексту Вы найдёте историю появления и развития этих преимуществ.

Библиотека изначально разрабатывалась в рамках работы над задачей создания Интернет-магазина для Bitrix, на котором предполагалась работа с гео-информацией для автоматизации заполнения форм о покупателе при работе с корзиной. На тот момент автор библиотеки ещё не знал, что в Bitrix уже был реализован некоторый встроенный функционал, поэтому для реализации задачи изначально было выбрано API от IpGeoBase, которое автор ранее уже неоднократно использовал для аналогичных целей.

IpGeoBase следовало использовать именно для API запросов о каждом IP-адресе, поскольку несмотря на то что на сайте сервиса предоставлялась возможность скачать geo-базу и необходимые библиотеки для работы с ней на языке PHP, указанные базы тем не менее почему-то сервисом не обновлялись и содержали таким образом для ряда стеков IP-адресов устаревшую информацию, по API же тот же сервис видимо предоставлял более свежую информацию.

Постоянные запросы к серверу IpGeoBase создавали бы замедление загрузки страницы (поскольку каждый запрос занимал определённое время, а без его завершения php сценарий не продолжал работу), поэтому пришла достаточно понятная идея – как-то кешировать эти запросы, чтобы каждый раз не обращаться к API удалённого сервера. К тому же API-сервис от IpGeoBase включал в ответ на запрос не только гео-данные об IP-адресе, а ещё и стек адресов, арендованных провайдером (то есть с какого IP адреса и по какой информация относится к одному стеку адресов).

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

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

Как уже было отмечено, работа по созданию библиотеки начиналась в рамках создания Интернет-магазина на CRM Bitrix, который построен на модульной структуре и для реализации необходимого функционала требовалась работа с гео-данными сразу в нескольких модулях. Для того чтобы избежать повторных запросов к удалённому API сервису, а также закешированной информации в базе данных, в код библиотеки nikolaevevgeGeoIp был добавлен функционал по кешированию ранее запрошенной информации о стеках IP-адресов в статическую переменную библиотеки.

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

Размышления о том, как повторно использовать уже полученные данные с гео-информацией без повторных запросов привели к идее о создании модуля или библиотеки, который можно было бы легко использовать и в других проектах. Так появилась первая версия файла библиотеки, включающая в себя необходимый функционал по получению гео-информации, а также её кешированию (как в базу данных, так и переменную). Каких-либо настроек первая версия файла библиотеки не требовала. Для связи с базой данных она использовала механизмы, предоставляемые API CMS Битрикс. На этом этапе также был автоматизирован процесс создания таблицы в базе данных, в которой хранится кеш с гео-информацией.

Дальнейшее развитие библиотека получила после того, как автор по рабочей задаче создал ещё один Интернет-магазин на CMS Joomla. И хотя именно в нём данная библиотека не применялась, тем не менее повторение классов Joomla давали возможность автору в приемлемые сроки адаптировать библиотеку и для этой CMS, что при появлении свободного времени вскоре и было сделано.

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

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

В варианте, который существует на момент выхода статьи — библиотека nikolaevevgeGeoIp:

В случае, если она используется до подключения CMS, автоматически распознаёт CMS, установленную в DOCUMENT_ROOT сайта и подключает необходимый функционал для работы с базой данных. Таким образом при установке системы нет необходимости прописывать логин и пароль пользователя от базы данных, а просто достаточно разместить файл с классом библиотеки и подключить его (либо настроить его автозагрузку).
В случае, если файлы CMS подключены до начала работы с гео-библиотекой, такой вариант также срабатывает корректно и файлы повторно не загружаются.

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

Bitrix\Main\Service\GeoIp\Manager::getDataResult(NULL,"ru");

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

Чуть позднее возникло пожелание более точно определять регионы операторов мобильной связи. Например, регион пользователей оператора МТС, находящихся в Ивановской области, определяется как Москва, а оператора Мегафон — как Санкт Петербург. Возникло предположение, что несмотря на информацию, указанную оператором в открытых источниках об IP-адресе, стеки адресов провайдера всё же могут быть разделены по регионам. Если это так, то оставалось практическим путём определить, какие стеки адресов к каким регионам относятся. При этом не утверждается, что работать должно именно так, то есть что один стек адресов может одновременно использоваться как регионом Москва, так и Ивановской области, а возможно, что у каких-то операторов это так, а у других – нет.

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

В рамках этого вопроса стала собираться база гео-информации на основе парсинга сайта RIPE точка NET. И хотя на момент выхода этой статьи вопрос по более точному определению регионов пользователей мобильных операторов в полной мере ещё не решился, как потом оказалось, сбор данных для собственной geo-базы оказался значимым для развития библиотеки.

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

Ближе к концу августа 2021 года на сайте API гео-сервиса IpGeoBase, на использовании которого была на тот момент построена работа библиотеки, появилась заглушка доменного регистратора. Достаточно длительная по времени недоступность сайта IPGeoBase была и ранее, при этом факт того, что данный сервис может вовремя не заплатить за домен было замечено впервые.

Примерно через несколько дней появилось предположение, что сайт библиотеки может заработать не скоро или вообще не заработать, кроме того было понятно, что даже если сервис вновь заработает, то происходящие периодически простои (если они продолжатся) не желательны для пользователей библиотеки, и автор решил создать свой гео-сервис. А как ранее было написано, сбор информации с сайта RIPE точка NET уже был произведён. Таким образом работа эта велась не с нуля.

В то же время на сайте библиотеки появилась информация о проблемах в работе IPGeoBase, а также о разработке собственного API-geo сервиса, с использованием которого в скором времени планировалось перевести библиотеку. Потенциальным пользователям было рекомендовано временно воздержаться от использования библиотеки, и дождаться на сайте информации о выходе версии на новом API и уже использовать её. Далее, примерно через день-два с сети Интернет появилась информация о том, что Rucenter, который являлся владельцем сервиса IPGeoBase, опубликовал информацию о прекращении поддержки сервиса IPGeoBase, хотя в официальном источнике автор сам этой информации не видел, а только обсуждения на сторонних ресурсах.

Тем не менее уже было понятно, что переход на свой geo-сервис был верным решением особенно при такой ситуации. Ещё примерно через неделю работа над API-geo сервисом и перевод кода библиотеки для работы с ним были закончены, о чём было сообщено на странице библиотеки. Эта же версия библиотеки и API получила функционал определения кода региона, к которому относится стек IP адресов. Такого функционала не было в библиотеке ранее, поскольку сервис IPGeoBase не предоставлял такой информации, хотя можно бы было использовать привязку к названию региона для получения такого кода. Написание кода региона принято аналогичное тому, которое использует библиотека SypexGeo, например код Ивановской области выглядит так RU-IVA.

Ещё чуть позднее выяснилось, что информация о стеках IP адресов, которая предоставляется сервисом RIPE точка NET, не всегда является точной в вопросе привязке к Региону. Так, например, оператору Билайн (в прошлом Corbina) выделен стек адресов с 128.72.0.0 по 128.73.255.255. В сервисе RIPE.NET данный стек описывается, как неделимый и, казалось бы, относящийся к городу Москва, при этом оператор поделил данный большой стек на множество составляющих, которые выделены под определённые регионы.

Для того чтобы выявлять такие стеки IP-адресов и корректно определять регионы, к которым они привязаны, как вариант, можно применять сопоставление с другими geo-сервисами (например, netgeoplugin) или делать запросы провайдерам.

Возможно, сейчас, когда Вы читаете данную статью данный функционал уже введён в библиотеку, тем не менее на момент написания стати автор библиотеки nikolaevevgeGeoIp планировал добавить возможность обращаться к базе данных по средствам PHP-PDO с целью расширить возможность применения библиотеки за пределы CMS Bitirx, Wordpres и Joomla. Таким образом ожидается развитие библиотеки и время покажет, какой она станет.

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

22.12.2021 (обновлено 22.12.2021)