Итак, у нас есть доска планирования здесь, в Matise. Обо всем этом Мауриц написал в своем посте почти год назад. Теперь это отлично работает, каждый день каждый может видеть, что он должен сделать за этот день. Но время от времени случается следующее:
Что происходит из-за токенов доступа. Точнее, из-за прогноза, обесценивающего их. Мауриц писал о 60-дневной дате истечения срока действия токенов, что до сих пор остается в силе. Но это означает, что нам приходилось обновлять доску планирования каждые 2 месяца. Что привело меня к сути этого сообщения в блоге: можем ли мы автоматизировать это?
Знак в потоке
Прежде всего, я начал с рассмотрения того, как прогноз обрабатывает вход в систему и где мы получаем токен доступа в процессе.
Я начал со страницы входа в прогноз. Выше показана страница входа в Harvest ID. Здесь мы должны автоматически войти в систему, чтобы перейти на следующую страницу.
Приведенная выше страница является результатом входа в систему. В HTML-коде страницы выбора учетной записи есть ссылка с идентификатором учетной записи, который мы ищем. Эта ссылка «https://id.getharvest.com/accounts/[accountID]» — это то, что нам нужно для последнего шага. Он возвращает перенаправление с accessToken в целевой ссылке. Выглядит достаточно легко, верно?
Автоматизация всего
Начав с азов, я воссоздал знак в потоке в Почтальоне. Таким образом, я знал, что шаги, которые я предпринимал, были возможны с наименьшим количеством заголовков и данных формы. Я взял нашу любимую технологию веб-сервера, парс-сервер, для реализации автоматизации. Это позволяет легко запускать сценарии и делать запросы, которые нам понадобятся.
Попробуйте запросы в Postman по этой ссылке.
Часть 1. Страница входа
Используя postman и некоторые пробы и ошибки, я понял, что для отправки учетных данных пользователя на страницу входа нам нужна следующая информация:
- Электронное письмо
- Пароль
- Токен подлинности
- Сеансовый файл cookie
Имя пользователя и пароль просты, это то, что я знаю. Другие 2, где это становится интересным. Если вы делаете GET-запрос к https://id.getharvest.com/sessions/new, он возвращает следующую форму:
Если вы посмотрите на второй тег ‹input›, мы найдем подлинность_токена. И когда мы смотрим на куки в инспекторе, мы находим _iridesco-identity_session.
Комбинируя эти знания с некоторыми библиотеками npm (request, cheerio), мы получаем следующий скрипт, который возвращает токен аутентификации и фиксирует сеанс cookie.
Как вы можете видеть, в итоге мы получаем AuthenticationToken в переменной, а сеанс аккуратно обрабатывается файлом cookie запроса («npmRequest.jar()»).
Баночка для печенья — очень полезный инструмент. К сожалению, мне потребовалось некоторое время, чтобы понять это. Если вы не создадите новый экземпляр файла cookie, запрос использует некоторый скрытый объект глобального хранилища для хранения ваших файлов cookie. Это привело к тому, что я был очень разочарован тем фактом, что он работал в моих вызовах почтальона, но не в моем коде javascript.
Часть 2. Вход в систему
Используя информацию, собранную на странице входа, адрес электронной почты и пароль, мы можем создать следующий запрос.
Теперь у нас есть токен сеанса, вошедшего в систему, в банке cookie.
Часть 3: Токен доступа
Окончательные запросы получают токен доступа, который мы ищем. С помощью некоторого причудливого кода регулярного выражения я получаю accountId и accessToken из ссылки.
Конечная точка /accounts/[accountId] возвращает перенаправление 302 с нужной нам ссылкой в заголовке местоположения. С показанным выше регулярным выражением я просто извлекаю accountId и accessToken для дальнейшего использования.
Использование кода
После объединения всех запросов с некоторой магией Parse.Promise я создал почасовую работу Parse. Чем, если вам интересно, я поделился как суть на github.
Запоздалые мысли
Теперь у нас есть токен доступа в базе данных. Мы можем делать с ним крутые вещи. Например, мы собираемся получать новый токен каждый день при запуске доски планирования, чтобы нам никогда не приходилось снова обновлять код доски планирования.
Примечание:
У меня автоматический вход выполняется каждый час, чтобы поддерживать актуальность моего токена доступа. Но когда я зашел на страницу безопасности Harvest ID, я заметил невероятное количество созданных мною сессий. Как только мы внедрим код на доске планирования, я, вероятно, изменю срок действия токена доступа на 18 часов вместо 60 дней, поэтому никогда не будет больше 18 активных сеансов.
