Найти в Дзене
Анна Шестопалова

История одного факапа: кривой API или уязвимость Power Query ?

Всех с 1-ым апреля! Шуток не будет )) Но будет каламбур. Если бы я писала книгу про Power Query, то вынесла бы эту фразу в эпиграф главы о функции Web.Contents() "Сейчас Великий POST. Кукисы с сайтов принимать грешно" Наткнулась на это изречение, когда в отчаянии искала как получить файлы cookie в ответ на запрос к веб-приложению. Но обо всем по порядку. Итак, задача заказчика - получить данные из web-приложения с помощью Power Query и построить отчет в Power BI. Получение данных было многоходовое. Проблемными были два шага: Шаг 1: отправить GET-запрос на получение данных; Шаг 2: отправить POST-запрос с данными, полученными на шаге 1. Казалось бы, все просто, но шаг 2 стабильно не работал !!!! Я использовала функцию Web.Contents. Она способна отправлять и get-, и post-запросы. Основной аргумент этой функции - многосоставный url. Проверить, что url составлен правильно можно, введя его в браузер. Тут-то ошибка и вскрылась. Потому что в браузере урлы обоих запросов отрабатывали корректно.

Всех с 1-ым апреля!

Шуток не будет ))

Но будет каламбур. Если бы я писала книгу про Power Query, то вынесла бы эту фразу в эпиграф главы о функции Web.Contents()

"Сейчас Великий POST. Кукисы с сайтов принимать грешно"

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

Итак, задача заказчика - получить данные из web-приложения с помощью Power Query и построить отчет в Power BI. Получение данных было многоходовое. Проблемными были два шага:

Шаг 1: отправить GET-запрос на получение данных;

Шаг 2: отправить POST-запрос с данными, полученными на шаге 1.

Казалось бы, все просто, но шаг 2 стабильно не работал !!!!

Я использовала функцию Web.Contents. Она способна отправлять и get-, и post-запросы. Основной аргумент этой функции - многосоставный url. Проверить, что url составлен правильно можно, введя его в браузер. Тут-то ошибка и вскрылась. Потому что в браузере урлы обоих запросов отрабатывали корректно. Разница с Power Query была лишь в том, что мой браузер видимо записывал какие-то куки-файлы, которые помогали выполнить второй запрос.

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

В ответ на первый GET-запрос никакие куки не приходили. Обычно, если куки нужны, то они приходят отдельной записью в ответе. Но ничего не было... Замена функции Web.Contents на Web.BrowserContents тоже не помогала. Несколько дней я внимательно штудировала форум техподдержки этого приложения, форум сообщества Power Query и вообще весь интернет на тему куков и не понимала, почему очевидные вещи уже не очевидны.

Загадка этого приложения так и осталась неразгаданной, хотя я грешу на кривой REST API . Решение было следующим: в неполноценный коннект "Приложение"-"Power Query" вставить прокси-сервер. Из Power Query отправлялся запрос на прокси-сервер, оттуда отправлялся запрос на языке Python к Приложению. Язык Python успешно ловил неуловимые куки, о которых, собака, не было ни слова в документации, и отправлял их вместе со вторым POST-запросом. Итоговый ответ от Приложения с прокси-сервера приходил в Power Query.

В принципе, можно было бы встроить python-скрипт и в Power Query, но дальше отчет размещался в службе Power BI и для обновления потребовался бы шлюз. А шлюз ставить не хотелось.

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

А какие самые странные факапы с подключением к данным были у вас?