Fetch: запросы на другие сайты

Что делать дальше?

И вот мы подбираемся к самому интересному: а где хранить пароли и в каком виде? Давайте сначала подумаем, где их хранить.

Что такое сессии?

Попробую рассказать в паре абзацев.

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

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

Fetch: запросы на другие сайты

Автоматическое использование браузера

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

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

Главный минус этого подхода – вы запускаете чужой код у себя на компьютере. Этот код может, например, содержать дополнительную защиту от автоматизации самого разного типа от детекторов headless-браузеров и до интеллектуального анализа поведения пользователей.

Выбираем правильное хэширование

Идею хранения паролей нашли, то есть хранения не паролей, а их хэшей. А вот какой алгоритм хэширования выбрать?

Давайте посмотрим на то, что пробовали выше – простая функция md5. Алгоритма его расшифровки нет, но тем не менее md5 не рекомендуется для использования. Почему?

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

    select password from passwords where hash='e10adc3949ba59abbe56e057f20f883e';

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

Помимо md5 есть множество алгоритмов хэширования, sha256, sha512 и еще целая толпа. Их сложность выше, но это не отменяет опять-таки существования таблиц с готовыми паролями.
Нужно что-то хитрее.

Заглушка для авторизации

Функции, связанные с авторизацией, будут лежать в отдельном файле и своем пространстве имен. Создадим файл auth.php в api/v1/common – там, где уже лежит helpers.php.
Если вы разбирали уроки админки, особенно третий, про серверную часть, то эти пути вам будут знакомы. Если у вас свой проект, то кладите auth.php куда удобно.
Главное, потом правильно указать пути.

Содержимое auth.php

И напоследок

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

Интеграция с базой данных

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

Для конвертации прав доступа в Mongo запрос существует toMongoQuery функция:

Как обойтись без шифрования. хэширование

Фокус в том, что не нужно хранить пароли в открытом виде, но и не нужно шифровать их с возможностью расшифровки. Пароли нужно хэшировать и в базе хранить не пароль, а его хэш.
Хитрым образом закодированную строку, которую нельзя расшифровать. Например, не password, а 5f4dcc3b5aa765d61d8327deb882cf99

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

Например, есть простая функция хэширования md5. Вот так она работает

Клиентская авторизация

С клиентской авторизацией действительно нет ничего сложного.

Согласно

, достаточно асинхронно загрузить

и, «повесить»

VK.init({appid: YOUR_APP_ID})

на событие

window.vkAsyncInit

, после чего уже можно вызвать функцию

VK.Auth.login(authInfo, YOUR_APP_PERMISSIONS)

, которая и выполнит авторизацию пользователя.

var vk = {
 data: {},
 api: "//vk.com/js/api/openapi.js",
 appID: YOUR_APP_ID,
 appPermissions: YOUR_APP_PERMISSIONS,
 init: function(){
  $.js(vk.api);
  window.vkAsyncInit = function(){
   VK.init({apiId: vk.appID});
   load();
  }

  function load(){
   VK.Auth.login(authInfo, vk.appPermissions);

   function authInfo(response){
    if(response.session){ // Авторизация успешна
     vk.data.user = response.session.user;
     vk.getFriends();
    }else alert("Авторизоваться не удалось!");
   }
  }
 },
 getFriends: function(){
  VK.Api.call('friends.get', {fields: ['uid', 'first_name', 'last_name'], order: 'name'}, function(r){
   if(r.response){
    r = r.response;
    var ol = $('#clientApi').add('ol');
    for(var i = 0; i < r.length;   i){
     var li = ol.add('li').html(r[i].first_name ' ' r[i].last_name ' (' r[i].uid ')')
    }
   }else alert("Не удалось получить список ваших друзей");
  })
 }
}

$.ready(vk.init);

По-сути, этот код делает следующее:

По готовности документа загружается API ВКонтакте, и, после его инициализации, вызывается метод

VK.Auth.login()

, который показывает всплывающее окно,

которое успешно «блочится» любой баннерорезкой

, в котором пользователь должен подтвердить своё согласие предоставить данные клиентскому приложению.

Функция

authInfo

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

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

Краткий обзор методов

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

1. Имитация браузера: выполнение запросов на основе данных полученных хакерскими методами, такими как анализ трафика, реверс-инжиниринг скриптов и так далее.
2. Автоматическое использование браузера. Сюда относится управление из скрипта настоящими браузерами (например, Chrome) через специальный API (например, с помощью Selenium WD), а также использование headless-браузеров (например PhantomJS).
3. Использование браузера вручную. Это не обязательно означает полный отказ от автоматизации скрейпинга, но подразумевает, что живой оператор будет видеть реальные страницы и выполнять на них реальные действия через пользовательский интерфейс.

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

Постановка задачи

На этот раз заказчик – другой веб-скрейпер, которому понадобилась помощь коллеги. Он хочет получить (для своего заказчика) данные с известного сайта Amazon. Некоторые из нужных ему данных отдаются только авторизованным пользователям. Разумеется, у заказчика есть аккаунт на Amazon, но проблема в том, что на этом сайте реализована защита от автоматической авторизации. Заказчику нужен модуль на Node.js, который эту защиту проходит. Естественно, речь идёт об инструменте для автоматической авторизации своим аккаунтом под свою ответственность, а не о взломе чужого аккаунта, например.

Проверяем возможности

Существует 3 метода у экземпляра Ability, которые позволяют проверять права доступа:

import { ForbiddenError } from 'casl'

ability.can('update', 'Post')
ability.cannot('update', 'Post')

try {
  ability.throwUnlessCan('update', 'Post')
} catch (error) {
  console.log(error instanceof Error) // true
  console.log(error instanceof ForbiddenError) // true
}

Первый метод вернет false, второй true, а третий выбросит ForbiddenError для анонимного пользователя, так как они не имеют права обновлять статьи. В качестве второго аргумента, эти методы могут принимать экземпляр класса:

const post = new Post({ title: 'What is CASL?' })

ability.can('read', post)

В этом случае can (‘read’, post) возвращает true, потому что в способностях мы определили, что пользователь может читать все статьи. Тип объекта вычисляется на основе constructor.name. Его можно переопределить создав статическое свойство modelName на классе Post, это может понадобится если для продакшн сборки используется минификация имен функций. Также можно написать свою функцию по определению типа объекта и передать ее как опцию в конструктор Ability:

import { Ability } from 'casl'

function subjectName(subject) {
  // custom logic to detect subject name, should return string or undefined
}

const ability = new Ability([], { subjectName })

Давайте теперь проверим случай, когда пользователь пытается обновить статью другого пользователя (я буду ссылаться на идентификатор другого автора как anotherId и к идентификатору текущего пользователя как myId):

const post = new Post({ title: 'What is CASL?', authorId: 'anotherId' })

ability.can('update', post)

В этом случае can(‘update’, post) возвращает false, поскольку мы определили, что пользователь может обновлять только свои собственные статьи. Конечно же, если проверить то же самое на собственной статье то получим true. Подробнее о проверках прав доступа можно посмотреть в разделе Check Abilities в официальной документации.

Проверяем работоспособность vue

Вроде бы, чего там может сломаться? Нам же практически не пришлось лезть в код vue, за исключением добавления кнопки Выйти в шапке админки.

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

    npm run build

Серверная авторизация

Серверная авторизация гораздо веселее. Механизм серверной авторизации для доступа к ВКонтакте API с стороннего сайта создан на базе протокола OAuth 2.0.

Процесс авторизации происходит следующим образом:

1. Необходимо в браузере пользователя показать страницу, где он разрешит приложению доступ к своим данным;
2. После успешной авторизации приложения браузер пользователя будет перенаправлен по адресу REDIRECT_URI, указанному при открытии диалога авторизации. При этом в GET-параметре будет передан код для получения ключа доступа;
3. Необходимо выполнить запрос с передачей кода и секретных данных приложения на специальный адрес, в ответ мы получим ключ доступа access_token, необходимый нам для совершения запросов к API.

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

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

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

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

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

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

Реализацию класса доступа к VK API по OAuth на PHP можно легко найти на гитхабе, что я и сделал (PHP >= 5.4).(Совершенно случайно оказалось, что этот класс, скорее всего, написан хабрапользователем vladkens, за что ему огромное спасибо)

Теперь перейдём к самому интересному.

<?php
 require_once('vk.php');
 session_start();
 
 function getPostStr($data, $default = false){ // возврачает строку - значение $_POST[$data]
  if(!isset($_POST[$data])) return $default;
  $data = $_POST[$data];
  $data = htmlspecialchars(strip_tags(trim($data)));
  return ($data != "" ? $data : $default);
 }
 function error($code, $text, $params = Array()){
  $result = Array('error' => Array('code' => $code, 'message' => $text));
  if(count($params) > 0) foreach($params as $key => $value) $result['error'][$key] = $value;
  die(json_encode($result));
 }
 
 $vkConf = Array(
  'appID'       => YOUR_APP_ID,
  'apiSecret'   => YOUR_API_SECRET,
  'callbackUrl' => YOUR_DOMAIN . '/auth.php',
  'apiSettings' => YOUR_APP_PERMISSIONS
 );
 
 $vk = (isset($_SESSION['accessToken']))
        ? new VK($vkConf['appID'], $vkConf['apiSecret'], $_SESSION['accessToken']) : null;
 
 function userIn($vk, $vkConf){ // Авторизация пользователя
  unset($_SESSION['accessToken']);
  $vk = new VK($vkConf['appID'], $vkConf['apiSecret']);
  $authorizeUrl = $vk -> getAuthorizeURL($vkConf['apiSettings'], $vkConf['callbackUrl']);
  error(-1, "Необходима авторизация ВКонтакте!", Array('url' => $authorizeUrl));
 }
 function getFriends($fields, $order, $vk){ // Получение списка друзей пользователя
  $userFriends = $vk -> api('friends.get', array('fields' => $fields, 'order' => $order));
  $result = Array();
  foreach($userFriends['response'] as $key => $value){
   $result[] = Array('firstName' => $value['first_name'], 'lastName' => $value['last_name'], 'uid' => $value['uid']);
  }
  echo json_encode($result);
 }

 $method = strtolower($api -> getStr("method"));

 switch($method){
  case "user.in"     : userIn($vk, $vkConf); break;
  case "friends.get" : getFriends(getPostStr("fields"), getPostStr("order"), $vk); break;
  default: Api::error(0, "Неверный запрос к Api");
 }
?>

Запросы на эту страницу мы будем посылать методом POST, где параметр

method

содержит название метода, который мы хотим выполнить на сервере.

Структура проекта

Проект имеет следующую структуру:

Теория

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

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

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

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

Признаки аутентификации:

Признаки авторизации:

Таким образом, для доступа к приложению требуется как аутентификация, так и авторизация. Если пользователь не может подтвердить свою личность (идентичность, identity), он не будет иметь доступа. И даже если пользователь подтвердил свою личность, но не авторизовался, в доступе ему будет отказано.

Токен

Под токеном в рамках настоящей статьи подразумевается JSON Web Token.

JWT — это открытый стандарт (RFC 7519), определяющий компактный и автономный способ безопасной передачи данных между сторонами в виде объекта формата JSON. JWT — это стандарт, т.е. все JWT являются токенами, но не все токены являются JWT.

Заключение

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

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

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

Вместо заключения

Проблемы с dev режимом во vue – это неприятный момент. Мы хотим и апишечку подергать, и все удобства vue-cli использовать. И на елку влезть, и ничего не ободрать.
Возможно, есть более изящный способ обойти эти проблемы в dev режиме, но я их пока не нашел. Поэтому приходится подпирать код лишними условиями.