Формы и вход: POST, cookies, сессии

Формы бывают двух пород, и разница не косметическая. GET-форма кладёт поля в строку запроса: поиск по каталогу превращается в /search?q=colly&page=2 — такой запрос отправляется обычным Visit с готовым URL, POST не нужен. POST-форма несёт поля в теле запроса: логин, комментарий, загрузка файла — всё, что меняет состояние или не должно светиться в адресной строке. Для POST у коллектора есть метод c.Post(url, map[string]string): ключи карты — имена input-полей формы, значения — то, что вы вводили бы руками. Важная деталь: c.Post — полноценный проход через конвейер colly. Сработает OnRequest, придёт OnResponse, OnHTML разберёт итоговый HTML так же, как после Visit. Редирект после успешного логина colly проходит сама, как это делает браузер, и колбэки увидят уже финальную страницу.

Сервер узнаёт пользователя по cookies: в ответ на логин он кладёт идентификатор сессии, и дальше каждая страница отдаётся с оглядкой на этот идентификатор. Весь colly логин cookies сводится к автоматике: у коллектора свой cookie-jar, и то, что пришло в Set-Cookie, вернётся в следующих Visit и Post без единой строки кода с вашей стороны. Достать cookies можно методом c.Cookies(url) — вернётся слайс []*http.Cookie, полезный для отладки и переноса сессии. Положить извне — c.SetCookies(url, cookies). Отсюда рабочая схема наследования сессии: скрапер залогинился, cookies вынули, создали второй коллектор с другими настройками и влили сессию через SetCookies — вход сохранится. Границы у этой аккуратности жёсткие, о них — сразу после кода.

Как понять, что вход удался? Не по коду ответа: редирект и 200 скажут и о странице с ошибкой «Неверный пароль». Надёжный признак — элемент, который существует только для залогиненных. На quotes.toscrape.com это ссылка выхода: селектор a[href='/logout'] срабатывает, когда сессия признана. Признак выбирается под сайт: на другом ресурсе это имя пользователя в шапке, кнопка «Мой кабинет», блок с балансом. Ошибка входа, кстати, живёт на той же странице: блок с текстом про неверный пароль ловится отдельным OnHTML — один проход отвечает сразу на оба исхода. Правило простое: проверка входа — поиск элемента, а не анализ статуса. Код ответа говорит, что страница отдалась, но не говорит, чья она.

Когда вход не срабатывает, претензии без лога не разбираются. Подвесьте OnRequest и OnResponse с печатью адреса и статуса — и вход превратится в читаемый диалог: POST на /login уходит, приходит 302 на главную, за ним GET, и вот тут видно, где сломалось. Статус 200 на странице логина после POST означает, что сервер не принял форму и вернул её с сообщением об ошибке — ищите блок ошибки отдельным OnHTML. 302, за которым снова /login, — потерялась сессия: cookies не доехали или коллектор сменился на полпути. Соединение закрылось без ответа — сайт режет клиента по заголовкам, и дальше уже территория урока про User-Agent. Такой лог из трёх строк экономит часы гаданий; я вешаю его на любой новый сайт до того, как писать боевые колбэки, и снимаю, когда вход стабилен.

Поисковые формы чаще всего GET — и тогда POST вам не нужен. Поля складываются в строку запроса, и «отправка» — это Visit с готовым адресом вида /search?q=термин&page=2. Схему адреса подглядывают в devtools: вкладка Network показывает, какой запрос улетел, когда вы искали руками. Осторожность нужна с кодированием значений: пробел и кириллица в адресе должны быть закодированы — net/url из стандартной библиотеки справляется, Values.Encode() собирает корректную строку запроса из карты параметров. GET-форма — самый благодарный случай скрапинга: никаких сессий, никаких токенов, страница для каждой комбинации параметров существует отдельно и отлично кэшируется. Не пропустите и обратную ситуацию: форма выглядит как логин, но метод у неё GET и поля видны в адресной строке — тогда и сессия не нужна, и весь сценарий сводится к одному Visit. Отдельный практический случай — страницы-фильтры без всякой формы: каталог, отфильтрованный по цене или тегу, часто выражается адресом, который собирается из параметров, и собирать такие адреса циклом удобнее, чем заполнять форму. Правило выбора одно: посмотрите в Network, что реально улетает, и воспроизводите адрес, а не жесты пользователя.

Третий слой сложности — формы с CSRF-токеном: сервер кладёт в разметку скрытый input, обычно input[name=csrf_token], и ждёт, что в POST придёт то же значение. Токен персональный: у вашей сессии он свой, чужой не подойдёт, угадать нельзя. Отсюда правило, которое нарушают все, кто спешит: логин с CSRF одним POST не работает — сервер отклонит его как запрос без токена или с чужим. Правильный порядок двухпроходный. Первый Visit открывает страницу формы и парсит скрытый input: e.ChildAttr("input[name=csrf_token]", "value") вынимает значение. Второй шаг — c.Post уже с токеном среди полей. Токен вынимается тем же коллектором, который будет постить: он привязан к сессии, и сессия должна доехать до POST несменённой.

Сессия есть — скрапера можно опознать и по другим приметам: какие заголовки он шлёт и как выглядит его User-Agent. Этому посвящён следующий урок про заголовки. А если хочется видеть, что происходит на каждом шаге входа — коды ответов, заголовки, редиректы, — вернитесь к уроку про OnRequest и OnResponse: лог запросов превращает непонятный отказ сервера в понятный диалог.