Singlea: Единый Вход Для Домена Своими Руками

ТЛ;ДР ОдинокийА — это набор пакетов Symfony, которые позволяют вам развернуть собственный PHP SSO, реализующий инфраструктуру.

SingleAuth .

Это, в свою очередь, позволяет пользователям веб-приложений, живущим на общем домене (уровня 2 и выше), перестать повторно заходить в SSO после того, как они уже один раз авторизовались (даже ради простого редиректа).

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

Пара оговорок.

1. Я не профессионал в академической речи, и местами эта статья может перейти в сторителлинг.

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

2. Недавно на Telegram-канале Пиво::PHP Там было замечание о шифровании.

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

   Эта статья не охватывает ни одной криптографической темы.

   Я бы даже не взялся сразу сказать, какую тему она достаточно освещает. Он выступает скорее как «неглубокий» обзор проекта SingleA и пробуждает интерес к технологиям, которые будут упомянуты в ходе этого обзора.

Хотелось бы начать с истории того, как он родился в принципе.

Точка невозврата

Единого подхода в компании еще не было, и я позволил себе сыграть изобретателя колеса.

Многие веб-приложения, с которыми я работал, работают именно так.

Заходишь к ним не авторизовавшись, заходишь на какой-нибудь централизованный сервис SSO аутентификации, авторизуешься.

Делаешь в приложении все что нужно и уходишь.

Затем вы заходите в соседнее веб-приложение, которое живет на «братском» домене, но не авторизуетесь там.

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

В результате пары редиректов вы снова в приложении и уже авторизованы, отлично.

Это можно грубо представить следующей диаграммой последовательности:



Через POST-запросы, указанные на схеме, SSO передает пользовательские данные в приложение.

Это не стандарт или непреложное правило, но это единственный подход, с которым я столкнулся на своем пути.

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

Вопрос: Если я уже вошел в SSO, зачем меня туда отправлять, даже для простого перенаправления обратно? С инженерной точки зрения я, конечно, знал ответ, но мой «внутренний пользователь» был озадачен.

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

Все дело в том, что зайдя в условный front.domain.org через sso.domain.org, я не могу просто пойти и начать отправлять запросы на api.domain.org, потому что последний обо мне ничего не знает. Тут самое время вспомнить про JWT, но возникает вопрос, кто его должен генерировать.

Не все SSO могут это сделать, и генерация JWT на стороне front.domain.org — не всегда простое дело: API может быть много, пользовательских свойств тоже, а что, если там конфиденциальные данные.

Похоже источник головной боли.

Но приведенный выше вопрос не мог выйти из моей головы, и я решил поискать на него ответ, взглянув на проблему с другой стороны.

Что изменится, если мы сделаем следующее предположение: все веб-приложения, привязанные к одному SSO (и сам SSO), работают с общим доменом (например, domain.org из примера выше).

Очевидно, что в этом случае они будут иметь доступ к файлам cookie, доступным для этого домена.

С этой мыслью началась работа над проектом, который сменил несколько названий и архитектур и стал «швейцарским ножом» при разработке проектов на основе сервис-ориентированной архитектуры или микросервисов.

Но вначале была только абсолютная уверенность, что это единственное предположение о предметной области может дать зеленый свет внедрению инструмента, который качественно изменит DX (опыт разработчика) для меня и моей команды.

Оставалось только собраться с мыслями.

(И, как оказалось позже, с силой.

)

Ээволюция проекта

Первая версия

на встрече в Нижнем Новгороде .

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

Что тогда произойдет на стороне клиентского веб-приложения, так это то, что с использованием этого файла cookie будет сделан запрос (под капотом) к SSO для создания токена пользователя (JWT), который будет добавлен к исходному запросу.

Если быть точным, то это делало не само клиентское приложение, а специальный клиент для SSO, который представляет собой Lua-скрипт для веб-сервера nginx, обрабатывающий запрос перед передачей его клиентскому приложению.

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

Об этом скрипте Lua я расскажу ближе к концу.

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

Справедливости ради стоит сказать, что утверждение об отсутствии «утомительной процедуры интеграции» крайне субъективно и может быть оспорено многими.

Читайте дальше, чтобы составить собственное мнение.

Но тогда осознание ошибок, свойственных подходу с фейковыми запросами пользователей, было еще впереди.

И неумелое заигрывание с Package by Feature не породило ничего, кроме путаницы в коде.

Функциональная архитектура и появление контрактов

К тому времени я успел осознать ряд своих ошибок и решил провести время с пользой: написать диссертацию и довести заявку до ума.

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

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

Контракты SingleA , напоминающий компонент Контракты Symfony .

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

По сути, код тех сервисных компонентов, которые были описаны в получившихся интерфейсах, был вынесен в отдельные бандлы Symfony: некоторые отвечали за генерацию JWT, некоторые отвечали за хранение пользовательских данных и данных, связанных с клиентскими приложениями (их конфигурации на стороне SSO, о чем я еще не раз расскажу позже).

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

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

Но он был совершенно для этого не приспособлен.

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

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

• Реализация генератора JWT не позволяла создавать токены с включенным шифрованием (JWE).

  Библиотека с поддержкой JWT существовала, но нужно было преодолеть нежелание переписывать большой слой кода.

• Манипулирование пользовательской сессией казалось откровенно плохой практикой, но разумной замены этому решению в голову не пришло.

Пакет Symfony

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

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

Чтобы понять (и принять) это решение, достаточно осознать, что служба SSO не должна выступать в качестве постоянного хранилища пользовательских данных, а должна быть лишь «слоем кэширования».

Компонент Symfony Cache позволяет использовать разные репозитории, что дает вам необходимую гибкость в настройке окончательного сервиса SSO. И все бы ничего, но вопрос с JWT с поддержкой шифрования так и не был решен, к тому же меня уже терзал червь сомнения относительно вопросов надежности SingleA в условиях «кровавого предприятия» и более-менее серьезные нагрузки.

Я решил, что лучше всего в такой ситуации обратиться к опыту старших товарищей, и отправился на встречу с коллегой из CDNnow .

Кто, как не они, может критически относиться к идее SSO-сервиса, действующего как единая точка отказа, да еще и скомпилированного на PHP. И я ни разу не пожалел об этой встрече.

(Дима, спасибо тебе большое!)

Качественный переход

• Объединение разрозненных бандлов в монорепозиторий.

• Symfony 6 и PHP 8.1 (хотя этот «.

  1», надо признать, не входил в мои планы и вышел уже на завершающем этапе — «спасибо» Николасу и компании за нетипичный шаг для Symfony Core-команды по увеличьте минимальную версию PHP в дополнительной версии требований).

• Иду из библиотеки Лкобуччи / JWT Луис Кобуччи веб-токен/JWT-фреймворк Флорента Морселли (также известная как Spomky), обеспечивающая поддержку JWE. Забегая вперед, хочу сказать, что я восхищаюсь Флораном и бесконечно благодарен ему за тот вклад, который он вносит в open-source и развитие JOSE в частности.

• Компонент безопасности — механизм цифровой подписи запросов — был переработан.

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

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

  Механизм цифровой подписи теперь используется для всех запросов SSO и привязан к времени отправки запроса.

  Я расскажу вам больше позже.

• Пользовательские данные и данные, относящиеся к клиентским приложениям, теперь хранятся в зашифрованном виде на стороне SSO, чтобы недобросовестным системным администраторам было сложнее их скомпрометировать.

  Ниже теме «тотального шифрования» будет посвящен отдельный раздел.

  Здесь скажу только, что это был важный шаг на пути к борьбе с собственной ленью, которая давно говорила «сойдет».

  Защита данных пользователей и клиентов SSO – это не прихоть и признак паранойи, это обязанность каждого, кто не хочет оказаться в новостях (или даже на скамье подсудимых).

На данный момент за моей спиной 4 этапа эволюции SingleA, и у меня такое ощущение, что я начал понимать Intel с их стратегией развития микропроцессоров.

ТИК Так .

Сначала вы ломаете «барьеры прошлого», чтобы увидеть доступные решения (и проблемы, которые вы раньше не замечали), а затем, понимая, что пути назад нет, реализуете их.

Одним из наиболее важных продуктов эволюции проекта стало создание фреймворка аутентификации SIngleAuth (позже давшего название всему проекту).

SingleAuth — структура аутентификации

на стороне службы SSO, а также ключевой особенностью является требование установки cookie с «сессией» пользователя в ответах на запросы к системе аутентификации — вход и выход. Этот «сеанс» в терминах проекта называется билетом, как упоминалось выше, и не имеет ничего общего с сеансом PHP.

В SingleA функция выхода из системы связана с системой аутентификации просто как обратная функция входа в систему.

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

Здесь я выделю лишь ключевые моменты.

• Реализация службы единого входа на основе SingleAuth должна включать методы регистрации клиентского приложения (клиента), входа и выхода пользователя, проверки его сеанса и генерации токена.

  Токен — это строка, позволяющая преобразовать ее в пользовательские данные на стороне клиента любым доступным способом.

  Например, токен может быть JWT, в котором закодированы все эти данные, а может быть уникальным ключом, с помощью которого клиент будет извлекать все необходимые данные из определенного хранилища, в которое SSO сначала поместит эти данные — это осталось к реализации.

• Особое место в рамках отведено роли «особенностей».

  Фича — это функционал сервиса, имеющий свою конфигурацию, которая задается для каждого клиента при регистрации.

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

  Как будет показано далее, именно так все и сделано в SingleA.

• Билет — это уникальный идентификатор «сеанса» пользователя (в смысле SingleAuth), который позволяет взаимодействовать между сервисом SSO и клиентом без непосредственного участия пользователя.

  Билет должен быть передан от SSO пользователю с использованием файла cookie, установленного на общий домен 2-го (или выше) уровня для всех «заинтересованных» веб-приложений.

• Регистрация клиента должна осуществляться посредством POST-запроса с передачей необходимых для регистрации параметров (зависит от реализации) в формате JSON. Ответ должен быть в формате JSON и содержать всю необходимую информацию в теле ответа.

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

SingleA: конструктор единого входа на основе PHP + Symfony.

Ядром проекта является одноименный бандл — nbgrp/singlea-bundle , который с помощью системы контрактов выступает «оркестратором» фич, обрабатывая входящие запросы.

Чтобы не пересказывать проектную документацию, расскажу о SingleA своими словами.

Начнем с обзора его возможностей.

Концептуальный вид

• Регистрация клиентов.

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

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

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

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

  Например, ключ проверки подписи в JWT на стороне клиента (подробнее о нем я скажу ниже).

  Секрет в этом случае играет особую роль.

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

  (Второй компонент — вращающиеся ключи на стороне обслуживания.

  )

• Методы SinlgeAuth. SingleA позволяет выполнять основные действия, указанные в рамках SingleAuth: аутентифицировать и завершать сеанс пользователя, проверять сеанс пользователя и генерировать токен пользователя.

  Предполагается, что первые 2 запроса делает пользователь (запросы браузера), а остальные являются внутренними запросами клиента к SSO и фактически выполняются модулем/скриптом, называемым ниже «SingleA client for nginx», который будет более подробно обсуждается ниже.

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

• Атрибуты пользователя.

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

  Я расскажу об этом межсетевом экране и его роли в работе весь ССО в следующем пункте, а тут просто добавлю 2 пункта.

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

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

• Область.

  В терминах SingleA Realm — это имя брандмауэра, обрабатывающего запрос.

  Система реалмов (вернее, механизм фиксации сессий в Symfony) позволяет одному пользователю авторизоваться через SSO сразу в нескольких независимых межсетевых экранах и, что более важно, с использованием разных User Provider. Другими словами, это позволяет одному пользователю использовать разных поставщиков удостоверений при аутентификации в разных приложениях, но через один и тот же единый вход. (Реальный пример использования нескольких IdP будет приведен ниже.

  )

• ЭЗапросить процессор.

  Говоря об эволюции проекта, я уже упоминал механизм цифровой подписи запросов.

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

• Функции ExpressionLanguage. Также стоит отметить, что забота о безопасности при обработке запросов носит добровольный характер.

  Проверка наличия тикета во внутренних запросах и действительности цифровой подписи (для тех клиентов, у которых эта функция активирована) является результатом использования специальных функций, относящихся к компоненту Symfony. ВыражениеЯзык .

  Здесь можно добавить, что SingleA предоставляет еще несколько функций: ограничить запросы клиентов по IP или подсети (эту функцию предполагается использовать для внутренних запросов на проверку сессии пользователя и генерацию токенов), а также ограничить запросы на регистрацию клиентов по IP. или подсети, или используя специальный регистрационный билет. Подробности этого механизма можно найти в проектная документация .

• Заполнение полезной нагрузки из внешнего источника.

  Еще одна функция, дополняющая платформу SingleAuth, — это Сборщик полезной нагрузки .

  Зачем это нужно? Например, вам может потребоваться получить роли пользователя в клиентском приложении как часть токена пользователя.

  Но SSO ничего не знает (и не может) о ролях пользователей на стороне клиента.

  Но он может сделать дополнительный HTTP-запрос к предопределенному веб-сервису, передав туда набор известных ему пользовательских атрибутов (точнее, только тех, имена которых были указаны при регистрации клиента в соответствующем параметре).

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

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

• Пользовательские сеансы PHP и сеансы SingleA. Проблема в том, что PHP и Symfony устроены таким образом, что если вы обновляете страницу приложения каждые 5 минут, ваша сессия по умолчанию никогда не истечет (поскольку продолжительность ее жизни будет постоянно увеличиваться).

  Для многих корпоративных приложений (именно с них начался проект SingleA) это плохой вариант. Они хотят, чтобы пользователи проходили повторную аутентификацию каждые N часов.

  В основном это связано с правилами техники безопасности.

  Чтобы удовлетворить этому условию, SingleA реализует разделение сеанса пользователя PHP и «сеанса» с точки зрения SingleA, которое длится до тех пор, пока атрибуты пользователя существуют в кеше.

  Срок службы элемента кэша фиксирован и истекает через определенный период времени.

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

  При пересохранении пользовательских атрибутов их время жизни будет продлено.

• Symfony Bundle, а не приложение.

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

  Контракты SingleA позволяют довольно просто заменить базовые реализации тех или иных функций и разработать собственные решения в соответствии со следующим набором простых правил:

  1. Создайте отдельный интерфейс конфигурации функций, унаследованный от общего интерфейса для всех функций SingleA\Contracts\FeatureConfig\FeatureConfigInterface (который содержит методы сериализации/десериализации).

     Это нужно сделать, даже если ваш интерфейс не содержит методов (что довольно странно, но всякое бывает).

  2. Создайте фабрику конфигурации для своей функции, реализовав в ней общий интерфейс для всех фабрик конфигурации функции — SingleA\Contracts\FeatureConfig\FeatureConfigFactoryInterface. Фабрика обрабатывает данные из запроса на регистрацию клиента и генерирует экземпляр конфигурации функции или возвращает любые возникающие ошибки.

     Следующий момент зависит от того, как вы храните конфигурации клиентских функций.

     Вот пример пакета nbgrp/singlea-redis-bundle, который является частью проекта.

     Этот бандл предоставляет механизм хранения клиентских конфигов и метаданных (в том числе времени последнего SSO-вызова с идентификатором клиента) в Redis с помощью другого удобного бандла — SncRedisBundle.

  3. В контейнере зависимостей вам нужно будет настроить службу маршалинга для вашего конфига (пример конфигурации службы можно найти в описании nbgrp/singlea-redis-bundle).

     Идентификатор этого сервиса нужно будет указать в конфигурации бандла, в параметре singlea_redis.config_managers (который также указан в описании).

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

Хранение пользовательских данных

Компонент, используемый для этого Кэш Symfony .

С первого дня работы над SingleA возникла необходимость предоставить администратору единого входа возможность принудительного выхода пользователя из системы.

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

Аннулирование кэша на основе идентификатора пользователя приводит к удалению атрибутов пользователя из кэша, а «сеанс» пользователя считается завершенным.

Но необходимым следствием этого решения является требование использования адаптера для пула кэшей, поддерживающего работу с тегами, то есть реализующего интерфейс Symfony\Contracts\Cache\TagAwareCacheInterface. Там, где требуется быстрое хранилище значений ключей, я предпочитаю использовать Redis. А для хранения тегированного кеша он подходит как нельзя лучше, за исключением обстоятельств облачности: записи тегов, содержащие ссылки на элементы кеша, живут вечно и не очищаются от элементов, удаленных по истечении времени жизни.

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

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

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

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

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

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

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

Удаление пользовательских данных по истечении срока их жизни — это только полдела.

Следующая цель — обеспечить их конфиденциальность на этапе кэширования, чтобы любопытный администратор не смог их «случайно» скомпрометировать.

Полное шифрование

.

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

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

Ключи, о которых идет речь, указываются в виде массива, что позволяет периодически их вращать.

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

Логика вращения описана в Теги: #программирование #открытый исходный код #php #symfony #lua-nginx-module #SSO #symfony 6 #SingleA

• Используйте Shopify, Чтобы Ваши Клиенты Влюбились В Ваш Продукт

  19 Oct, 24

• Типы Программ Для Привлечения Пользователей

  19 Oct, 24

• Для Вашей Интернет-Безопасности Получите Ip-Адреса И Устройства Traceemail.

  19 Oct, 24

• Страны-Лидеры По Доходам И Количеству Загрузок Приложений В App Store И Google Play – Отчет App Annie

  19 Oct, 24

• «Игры С Открытым Миром Должны Перестать Вручную Создавать Дизайн И Сюжет»

  19 Oct, 24

• Google Догнал Рамблер По Трафику Из Поисковых Систем (Данные Liveinternet)

  19 Oct, 24

• В России Запустили Реестр Отечественного По

  19 Oct, 24

• Что Ждет Тебя По Дороге Домой? Гео-Сигнализация - Мобильное Приложение, Предупреждающее В Нужный Момент

  19 Oct, 24

• Сумасшедший Colormatrixfilter.

  19 Oct, 24

• Склады Iphone Стремительно Пустеют

  19 Oct, 24