Authomatic: python библиотека для аутентификации и авторизации

Аутентификация в соцсетях

Уверен, эта картинка знакома всем:

Это часто называют аутентификацией в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.

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

Лучшее из двух миров

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

Как использовать

Как разработчик вы должны разбираться в работе этого метода аутентификации. Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth2 (некоторые используют OAuth1, например Twitter). Разберёмся, что такое OAuth. Соцсеть — это сервер ресурсов, ваше приложение — клиент, а пытающийся войти в ваше приложение пользователь — владелец ресурса. Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).

Для реализации такого механизма вам может понадобиться зарегистрировать своё приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport, Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.

Рекомендации по аутентификации на основе токенов

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

Правильный веб-токен. Хотя существует целый ряд веб-токенов, ни один из них не может обеспечить ту же надежность, которую предоставляет веб-токен JSON (JWT). JWT считается открытым стандартом (RFC 7519) для передачи конфиденциальной информации между несколькими сторонами. Обмен информацией осуществляется цифровой подписью с использованием алгоритма или сопряжения открытого и закрытого ключей для обеспечения оптимальной безопасности.
Приватность.
Использование HTTPS-соединений. HTTPS-соединения были построены с использованием протоколов безопасности, включающих шифрование и сертификаты безопасности, предназначенные для защиты конфиденциальных данных

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

Что такое идентификация?

Предположим, что есть определенная система или база данных, где содержится ряд из параметров (идентификаторов), например:

  • ID пользователя;
  • ФИО (фамилия, имя и отчество);
  • номер телефона;
  • IMEI-устройства;
  • адрес электронной почты;
  • логин (никнейм);
  • реквизиты банковской карты;
  • номер автомобиля;
  • серийный номер (штрих-код);
  • трек-номер;
  • смарт-карта;
  • адрес веб-сайта;
  • и т. д.

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

Для большего понимания давайте рассмотрим на примере простой ситуации. Вы находитесь дома, занимаетесь своими делами: смотрите фильмы для взрослых, делаете физические упражнения или читаете статью про кибербезопасность на моём сайте. В один момент Вы слышите звонок в дверь, прекращаете заниматься своей деятельностью и направляетесь открывать. Подойдя к двери смотрите в глазок, но никого не видите, спрашиваете: «Кто там?» и слышите в ответ: «Это я, ИМЯ человека!». Имя человека по ту стороны двери, в данной ситуации, является идентификатором. Правильный или неправильный ответ на вопрос — процесс идентификации.

Рассмотрим на примере другой ситуации. Вы совершаете звонок в банк с целью получить какую-либо информацию по Вашей банковской карте. Сотрудник, отвечающий на Ваш звонок, прежде чем предоставить информацию, обязан Вас идентифицировать. Помимо номера телефона, он может запросить у Вас другой идентификатор, например, номер банковской карты или ФИО. Ваш ответ, в данном случае — идентификация.

Основные определения

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

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

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

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

Подготовка к реализации системы аутентификации

Даже несмотря на то, что наш запрос на данный момент заканчивается ошибкой, мы наглядно показали как вписывается Identity в жизненный цикл приложения ASP.NET. Следующий шаг — создать контроллер, обрабатывающий запрос к URL /Account/Login, для отображения формы входа в приложение. Добавьте сначала новый класс view-model в файл UserViewModels.cs:

Новый класс модели содержит свойства Name и Password, декларированные атрибутом Required, который говорит системы валидации модели, что эти свойства не должны иметь пустых значений. В реальном проекте не забывайте также добавлять клиентскую проверку при вводе пользователем имени и пароля. В данном проекте мы пропустим эту проверку, т. к. основная наша цель — разобраться в ASP.NET Identity.

Теперь добавьте контроллер Account в наше приложение, с кодом, показанным в примере ниже, который содержит две перегруженные версии метода Login

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

Хотя этот код еще не относится к аутентификации пользователей, контроллер Account все же содержит некоторую полезную инфраструктуру, не относящуюся к ASP.NET Identity.

Во-первых, обратите внимание, что оба метода Login принимают строковый аргумент returnUrl. Когда пользователь запрашивает URL-адрес с ограниченным доступом, он перенаправляется по адресу /Account/Login со строкой запроса, содержащей адрес страницы с ограниченным доступом

Например, если сейчас вы запросите адрес /Home/Index, вас перенаправит на URL следующего вида:

/Account/Login?ReturnUrl=%2FHome%2FIndex

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

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

Для этого мы применили атрибут Authorize к контроллеру Account и добавили атрибут AllowAnonymous к некоторым методам действий. Это позволяет ограничить методы действий для авторизованных пользователей по умолчанию, но открыть доступ неавторизованным пользователям для входа в приложение.

Наконец, мы добавили атрибут ValidateAntiForgeryToken который работает в связке с классом HtmlHelper, используемом в Razor в представлениях cshtml. Вспомогательный метод AntiForgeryToken защищает от межсайтовой подделки запросов CSRF, благодаря тому, что генерирует скрытое поле формы с токеном, который проверяется при отправке формы.

Последний подготовительный шаг — создание формы входа в приложение. Добавьте в папку /Views/Account файл представления Login.cshtml:

В этой разметке стоит обратить внимание на использование вспомогательного метода Html.AntiForgeryToken и создание скрытое поля с сохранением параметра returnUrl. В остальном — это обычная форма, генерируемая с помощью Razor

Итак, мы завершили подготовку к созданию системы аутентификации. Запустите приложение и перейдите по адресу /Home/Index – система перенаправит вас на страницу входа:

Резюме

Основные выводы

Начиная с 2017 года резко возрос процент использования строгой аутентификации. Те, кто не использует строгую аутентификацию, недооценивают свой риск для бизнеса и клиентов. Тем не менее, пароли находятся на пути «в могилу». Развивающаяся нормативно-правовая среда обещает ускорить внедрение строгой аутентификации для потребительских приложений. Создание надёжной основы аутентификации позволяет компаниям сместить акцент с удовлетворения нормативных требований на удовлетворение потребностей клиентов. При выборе метода корпоративной аутентификации внутри предприятия требования регуляторов уже не являются значимым фактором. В эпоху фишинга злоумышленники могут использовать корпоративную электронную почту для мошенничества,Google усилил свою защиту внедрив строгую аутентификацию.

Рекомендации

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

Проведите тщательную инвентаризацию и оценку важности корпоративных данных и защитите их в соответствии с важностью. нет, правда, в отчёте так и написано “low-risk”, очень странно, что они недооценивают важность этой информацииИспользуйте строгую аутентификацию на предприятии

Безопасно ли использование токенов?

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

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

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

Токен и смарт-карта

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

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

На фотографии изображена типичная смарт-карта и считыватель.

Однако вернемся к корпоративной безопасности.

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

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

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

Авторизация и аутентификация: разница и типы

Есть несколько типов определения подлинности, различающихся по уровню защиты и использованию:

  • Защита с паролем. Юзер знает ключ, неизвестный никому. Сюда же относится идентификация через получение SMS;
  • Привлечение предметов. Привлекают компании и фирмы. То есть тут используются карточки, брелки, флешки и прочее;
  • Биометрическая проверка. Проверяется глазная сетчатка, голос, отпечатки пальцев. Это практически самая мощная системная защита;
  • Скрытые данные. Чаще всего привлекается для защиты ПО. Проверяется кэш обозревателя, местоположение, которое установлено на компьютер.

Пароли

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

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

Специальные предметы

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

Биометрические системы

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

Отличие авторизации от аутентификации

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

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

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

Требования нормативных документов к механизму идентификации и аутентификации

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

Прежде всего, обратимся к формализованным требованиям в
области защиты информации, попробуем в них найти ответ на вопрос, какими же
функциями должен быть наделен механизм идентификации и аутентификации?
Формализованные требования к механизму идентификации и аутентификации
пользователей задаются действующим сегодня нормативным документом
«Гостехкомиссия России. Руководящий документ. Средства вычислительной
техники. Защита от несанкционированного доступа к информации. Показатели
защищенности от НСД к информации».

Для СЗИ от НСД, используемых для защиты конфиденциальной
информации (5 класс СВТ) требования к механизму идентификации и аутентификации
состоят в следующем:

●     Комплекс
средств защиты информации (КСЗ) должен требовать от пользователей
идентифицировать себя при запросах на доступ.

●     КСЗ
должен подвергать проверке подлинность идентификации — осуществлять
аутентификацию.

●     КСЗ
должен располагать необходимыми данными для идентификации и аутентификации.

●     КСЗ
должен препятствовать доступу к защищаемым ресурсам неидентифицированных
пользователей и пользователей, подлинность идентификации которых при
аутентификации не подтвердилась.

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

Заметим, что в требованиях к СВТ 4-го класса защищенности
вообще задачи идентификации и аутентификации пользователя при входе в систему и
при запросе на доступ разделены на две самостоятельные задачи, кроме того,
здесь появляется некое понятие «субъект» в общем виде.

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

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

Чем двухуровневая проверка лучше одноуровневой

Как токены работают?

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

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

Хотя эти традиционные системы аутентификации токенов все еще действуют сегодня, увеличение количества смартфонов сделал аутентификацию на основе токенов проще, чем когда-либо. Смартфоны теперь могут быть дополнены, чтобы служить генераторами кодов, предоставляя конечным пользователям коды безопасности, необходимые для получения доступа к их сети в любой момент времени. В процессе входа в систему пользователи получают криптографически безопасный одноразовый код доступа, который ограничен по времени 30 или 60 секундами, в зависимости от настроек на стороне сервера. Эти мягкие токены генерируются либо приложением-аутентификатором на устройстве, либо отправляются по запросу через SMS.

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

Двухфакторная аутентификация

Почему стоит использовать токены авторизации?

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

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

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

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

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

Единая точка входа (Single Sign On, SSO)

Основные понятия AAA

Прежде чем мы познакомимся с протоколами RADIUS и TACACS+, разберемся с основными понятиями механизма AAA. Для примера будем использовать процесс законного проникновения в помещение с контролем доступа.

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

Авторизация (authorization) – следующий шаг после успешной аутентификации. Заключается в проверке прав доступа к помещению того человека, который прошел аутентификацию. Возможно, у человека есть право проникнуть в первое помещение, но запрещено прохождение дальше. На сетевых устройствах права доступа чаще всего определяют перечень команд, которые может выполнить пользователь, прошедший аутентификацию. Например, сетевому инженеру с 1-м уровнем доступа разрешен только просмотр конфигурации устройства с помощью команды show, а инженеру с 2-м уровнем доступно внесение изменений. На AAA-серверах операторов связи право доступа может определять принадлежность абонента к какому-либо тарифному плану.

Учет (аccounting) – параллельный с аутентификацией и авторизацией этап, который записывает в журнал успех или неудачу данных процессов, смог человек проникнуть в помещение или нет, получил ли пользователь доступ к сетевому устройству и, если да, то какие действия на нем совершал. Этот процесс важен с точки зрения безопасности и контроля доступа, так как позволяет определять потенциальные угрозы и искать «дыры» в системе.

На практике в сетях операторов связи AAA-процесс выглядит следующим образом:

  1. Абонент подключается к устройству доступа AGW (Access Gateway) или Network Access Server (NAS) и вводит свой логин и пароль.
  2. AGW (NAS) формирует и посылает запрос аутентификации к AAA-серверу и ожидает ответ.
  3. AAA-сервер обращается к DPI-системе или серверу биллинга по протоколу RADIUS для проверки логина абонента и пароля.
  4. AAA-сервер формирует ответ и отсылает его обратно на AGW (NAS).
  5. Если аутентификация пройдена, то AGW (NAS) пропускает абонента в сеть, но пока еще не предоставляет ему никаких услуг.
  6. Если пользователь пытается выйти в Интернет (вводит URL в строке браузера), AGW (NAS) формирует новый запрос AAA-серверу для авторизации.
  7. ААА-сервер вновь обращается к DPI-системе или серверу биллинга, чтобы получить информацию о тарифном плане и подключенных абоненту услугах.
  8. Получив положительный ответ от биллинга, ААА-сервер посылает ответ на AGW (NAS), и абонент получает доступ к Интернету в соответствии с настройками, установленными для тарифного плана.

О применении СКАТ DPI для тарификации и политик абонентов мы рассказывали в статье про реализацию L3 BRAS, но вскоре остановимся на этой функции подробнее.

OAuth 2. Общая схема работы

Если вы разрабатываете приложение (бот для телеграма, плагин для общедоступной CRM и т.д.), которое может быть полезно для любого пользователя Модульбанка, вы можете авторизовывать пользователей через сервер авторизации Модульбанка по OAuth подобному протоколу. Схема авторизации пользователей идентична протоколу OAuth 2.0, за небольшим исключением что сервер авторизации Модульбанка кроме формата x-www-form-urlencoded также поддерживает формат json в теле запроса. Для того чтобы стороннее приложение могло совершать запросы к API от лица конкретного пользователя, приложению необходимо получить токен авторизации, подтверждающий что пользователь предоставил приложению права на выполнение тех или иных действий.

!

Важно! Если вы хотите авторизовывать пользователей Модульбанка по протоколу OAuth, ваше приложение должно быть зарегистрировано у нас. Для регистрации приложения напишите нам письмо на api@modulbank.ru

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

Схема получения токена авторизации пользователя сторонним приложением.

Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий