Как парсить данные за страницами логинасессии, куки и CSRF

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

Это руководство показывает, как парсить данные за страницами логина с помощью Python. Вы создадите небольшой работающий парсер, который проверяет форму логина, отправляет учётные данные через requests.Session, передаёт куки сессии (и CSRF-токен) в аутентифицированные запросы, а затем читает защищённый контент. В качестве безопасной цели на протяжении всего руководства используется публичный учебный сайт quotes.toscrape.com/login. Раздел о законности в конце не является шаблоном: он устанавливает единственное жёсткое правило, которое делает всё это обоснованным, поэтому прочитайте его перед тем, как применять этот код к реальному аккаунту.

Что вы создадите

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

• Form inspection чтение имён полей формы логина и URL действия из её HTML.
• CSRF token извлечение скрытого токена из формы и его воспроизведение при отправке.
• Session login отправка учётных данных через постоянный requests.Session.
• Cookie carry-over повторное использование сессии, чтобы куки передавались с каждым последующим запросом.
• Authenticated fetch запрос защищённой страницы и подтверждение авторизации.

Почему обычный запрос не работает за логином

Отправьте обычный requests.get() на страницу, требующую логина, и вы получите один из двух неотвечающих ответов: перенаправление на форму входа или HTML самого логина со статусом 200. В любом случае защищённый контент отсутствует. Сервер закрывает доступ к странице по сессии, которую он не видит, потому что ваш скрипт никогда не аутентифицировался и не отправляет куки, подтверждающие это.

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

Предварительные требования

Несколько вещей, которые необходимо подготовить перед написанием кода. Ни одна из них не займёт много времени.

Базовые знания Python. Вы должны уметь писать и запускать скрипты, а также устанавливать пакеты с помощью pip. Если парсинг HTML для вас нов, наше руководство по использованию BeautifulSoup в Python охватывает то, что предполагает этот учебник.

Python версии 3.8 или выше. Проверьте командой python --version. Если его нет, установите с python.org или через дистрибутив, например Anaconda.

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

Аккаунт Crawlbase и JS-токен (для последнего шага). Когда ваша реальная цель рендерит контент с помощью JavaScript или блокирует обычные клиенты, вы будете маршрутизировать аутентифицированный запрос через Crawling API. Зарегистрируйтесь, откройте панель управления и скопируйте JavaScript (JS) токен. Относитесь к нему как к паролю и не добавляйте в систему контроля версий.

Настройка проекта

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

python --version

python -m venv login_env
source login_env/bin/activate

pip install requests beautifulsoup4

На Windows активируйте окружение командой login_env\Scripts\activate вместо строки с source. Две зависимости выполняют основную работу: requests управляет HTTP-сессией, а beautifulsoup4 парсит форму логина, чтобы вы могли читать имена полей и извлекать CSRF-токен.

Шаг 1: проверка формы логина

Прежде чем отправлять учётные данные, необходимо точно знать, что ожидает форма: URL, на который она отправляется, имена полей ввода и любые скрытые значения. Откройте страницу логина в браузере, щёлкните правой кнопкой мыши по форме и выберите «Проверить». На учебной цели форма отправляется на /login и содержит поле username, поле password и скрытое поле csrf_token. Реальные сайты различаются, поэтому всегда подтверждайте эти имена по живому HTML, а не предполагайте.

Ту же структуру можно прочитать программно. Получите страницу логина, загрузите её в BeautifulSoup и выведите поля формы, чтобы знать, что отправлять.

import requests
from bs4 import BeautifulSoup

LOGIN_URL = "https://quotes.toscrape.com/login"

page = requests.get(LOGIN_URL)
soup = BeautifulSoup(page.text, "html.parser")

for field in soup.select("form input"):
    print(field.get("name"), "->", field.get("type"))

Запустите скрипт, и вы увидите напечатанные три имени поля, включая скрытый csrf_token. Это скрытое значение является деталью, которую большинство новичков в парсинге логинов упускают: сервер выдаёт его на странице логина и отклоняет любой POST, который не возвращает его обратно, что именно и делает защита Cross-Site Request Forgery.

Шаг 2: вход через сессию и CSRF-токен

Теперь отправьте учётные данные. Ключом является использование объекта requests.Session, а не одноразового requests.post. Сессия сохраняет куки между запросами, поэтому после того, как сервер устанавливает куки сессии при успешном входе, каждый последующий запрос через ту же сессию автоматически отправляет куки, и сервер продолжает воспринимать вас как авторизованного.

Поток такой: выполните GET страницы логина для получения свежего CSRF-токена (и начальных куки), извлеките токен из скрытого поля ввода, затем выполните POST с именем пользователя, паролем и тем же токеном обратно на URL действия формы через сессию.

import requests
from bs4 import BeautifulSoup

LOGIN_URL = "https://quotes.toscrape.com/login"
USERNAME = "your-username"
PASSWORD = "your-password"

session = requests.Session()

# GET the form first to receive a fresh CSRF token and cookies.
login_page = session.get(LOGIN_URL)
soup = BeautifulSoup(login_page.text, "html.parser")
token = soup.find("input", {"name": "csrf_token"})["value"]

payload = {
    "csrf_token": token,
    "username": USERNAME,
    "password": PASSWORD,
}

response = session.post(LOGIN_URL, data=payload)
response.raise_for_status()

# The site shows a "Logout" link only when authenticated.
if "Logout" in response.text:
    print("Login succeeded; session cookies:", session.cookies.get_dict())
else:
    print("Login failed; still on the sign-in page.")

Запустите скрипт, и при успешном входе вы увидите Login succeeded, за которым следуют куки сессии, установленные сервером. Эти куки являются вашим удостоверением личности для всего последующего. Проверка наличия ссылки Logout является простым и надёжным тестом успеха: этот текст появляется только для аутентифицированного пользователя, поэтому его присутствие подтверждает, что сессия принята, а не просто полагается на код статуса.

Шаг 3: получение защищённой страницы и её парсинг

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

PROTECTED_URL = "https://quotes.toscrape.com/"

# The same session sends the login cookie automatically.
page = session.get(PROTECTED_URL)
page.raise_for_status()

soup = BeautifulSoup(page.text, "html.parser")
records = []

for card in soup.select(".quote"):
    records.append({
        "text": card.select_one(".text").text.strip(),
        "author": card.select_one(".author").text.strip(),
    })

print(len(records), "records read while authenticated")

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

Шаг 4: передача сессии в Crawling API

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

import requests

JS_TOKEN = "YOUR_CRAWLBASE_JS_TOKEN"
TARGET_URL = "https://quotes.toscrape.com/"

# Reuse the cookies from the logged-in session in Step 2.
cookie_pairs = [f"{k}={v}" for k, v in session.cookies.get_dict().items()]
cookie_header = "; ".join(cookie_pairs)

params = {
    "token": JS_TOKEN,
    "url": TARGET_URL,
    "cookies": cookie_header,
    "country": "US",
}

api = requests.get("https://api.crawlbase.com/", params=params)
api.raise_for_status()
print(api.text[:500])

Параметр cookies принимает тот же формат key1=value1; key2=value2, что и отправляет браузер, поэтому мы объединяем словарь куки сессии в одну строку заголовка. Crawlbase передаёт эти куки с запросом, который он рендерит, поэтому сайт воспринимает вызов как авторизованный, а затем возвращает отрендеренный HTML для парсинга с тем же кодом BeautifulSoup из шага 3. Если вы делаете несколько аутентифицированных вызовов подряд и хотите сохранить сессию между ними, смотрите раздел FAQ ниже о параметре cookies-session.

Как выглядит вывод

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

[
  {
    "text": "The world as we have created it is a process of our thinking.",
    "author": "Albert Einstein"
  },
  {
    "text": "It is our choices that show what we truly are.",
    "author": "J.K. Rowling"
  }
]

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

Обработка «запомнить меня» и истёкших сессий

Два практических нюанса возникают, как только вы выходите за рамки единственного прогона. Первый связан с флажком «Запомнить меня». Когда форма его предлагает, это просто ещё одно поле формы, часто флажок с именем вроде remember. Проверьте форму, и если флажок соответствует значению, добавьте его в ваш payload (например, "remember": "on"). Сайты, которые это поддерживают, возвращают более долгоживущие куки, поэтому ваша сессия выживает между запусками скрипта, а не истекает при остановке. Устанавливайте его только когда форма действительно его имеет; выдуманные поля, которые сервер не ожидает, могут привести к сбою логина.

Второй нюанс связан со сроком действия. Куки логина не постоянны. Они истекают по таймеру, при выходе из системы в другом месте или когда сайт ротирует сессии. Признак, ваш парсер вдруг начинает получать страницу входа вместо контента. Обработайте это, обнаружив сбой (ссылка Logout исчезла, или вас перенаправили на /login) и повторно запустив поток логина из шага 2 для создания свежей сессии перед повторной попыткой. Встроив эту проверку с самого начала, вы избавите себя от тихого парсинга страниц входа в течение часа.

Как оставаться незаблокированным

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

• Соблюдайте темп запросов. Интенсивный обход защищённых страниц в жёстком цикле является самым быстрым способом получить помеченную сессию. Распределяйте запросы и добавляйте между ними короткую паузу.
• Отправляйте тот же CSRF-токен, который предоставила форма. Повторное использование устаревшего токена или его пропуск является распространённой причиной отклонения POST с логином. Всегда сначала выполняйте GET формы и воспроизводите её текущий токен.
• Следите за кодами статуса. Прогон, начавший возвращать перенаправления или проверки, сигнализирует, что сессия истекла или уровень IP уже недостаточен. Откатывайтесь и повторно аутентифицируйтесь, а не делайте слепые повторные попытки.
• Используйте ротацию для сложных целей. Когда один IP постоянно провоцирует проверки, Crawling API ротирует через резидентные адреса за вас; если вы строите собственный стек, Smart AI Proxy предоставляет ту же ротацию в качестве подключаемого эндпоинта.

Для более широкой стратегии смотрите как парсить сайты без блокировок и, когда защищённая страница рендерится на клиенте, парсинг JavaScript-страниц с Python.

Законно ли парсить данные за логином?

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

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

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

Часто задаваемые вопросы

Почему обычный запрос возвращает страницу логина вместо моих данных?

Потому что сервер закрывает доступ к странице по сессии, которую ваш скрипт никогда не устанавливал. Обычный requests.get() не отправляет куки логина, поэтому сервер воспринимает вас как анонимного и возвращает перенаправление на форму входа или HTML формы со статусом 200. Чтобы получить контент, необходимо сначала аутентифицироваться, а затем отправлять куки сессии с каждым запросом, что requests.Session делает автоматически.

Как обработать CSRF-токен в форме логина?

Сначала отправьте GET-запрос на URL логина, распарсите возвращаемый HTML и прочитайте скрытый CSRF-ввод (часто называемый csrf_token) из формы. Включите это точное значение в payload, который вы отправляете POST-запросом обратно на URL логина. Некоторые сайты ротируют токен при каждом запросе или используют более одного, поэтому всегда выполняйте GET формы свежим и тщательно проверяйте её, а не жёстко кодируйте токен.

Что меняет «Запомнить меня» в запросе?

Это дополнительное поле формы, обычно флажок. Когда вы включаете его в payload POST (например, "remember": "on"), сайты, которые это поддерживают, выдают более долгоживущие куки, поэтому сессия выживает между запусками скрипта, а не истекает при остановке. Добавляйте поле только если форма действительно его имеет; отправка полей, которых сервер не ожидает, может сломать логин.

Мой парсер начал возвращать страницы логина в середине прогона. Что произошло?

Ваши куки сессии почти наверняка истекли или были признаны недействительными из-за таймера, выхода из системы в другом месте или ротации сессий на сайте. Обнаружьте это (ссылка Logout исчезла, или вас перенаправили на /login) и повторно запустите поток логина для создания свежей сессии перед повторной попыткой. Встроив эту проверку с самого начала, вы не будете тихо парсить страницы входа.

Могу ли я парсить аккаунт другого человека таким образом?

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

Когда следует использовать Crawling API вместо обычных запросов?

Используйте обычные requests, когда защищённая страница является статическим HTML, как в учебной цели здесь. Обращайтесь к Crawling API, когда ваша авторизованная цель рендерит контент с помощью JavaScript или блокирует автоматизированные клиенты. Сохраните тот же логин, затем передайте куки сессии в API через его параметр cookies, чтобы он рендерил через доверенный IP и возвращал готовый контент.

IK

Ian Kalvin

Инженер технической поддержки · Crawlbase

Инженер технической поддержки в Crawlbase, пишет с переднего края того, что на самом деле ломается в продакшене при скрейпинге и в прокси-конфигурациях.

NZ

Neil Zamora

Старший архитектор · Crawlbase

Старший архитектор в Crawlbase, сосредоточен на системах, стоящих за краулингом в больших масштабах: ротация прокси, устойчивость к anti-bot и API, скрывающие эту сложность.