Comment scraper les données derrière les pages de connexionsessions, cookies et CSRF

Une grande partie des données avec lesquelles vous souhaitez vraiment travailler se trouve derrière une connexion : votre propre tableau de bord analytique, un outil de reporting interne, un compte SaaS dont le bouton d'export s'arrête au trimestre dernier, un espace membres que vous administrez. Une simple requête HTTP vers ces pages vous donne une redirection vers le formulaire de connexion, car le serveur ne sait pas qui vous êtes. Pour atteindre le contenu, vous devez faire ce que fait un navigateur : vous connecter, conserver la session, et envoyer cette session avec chaque requête ultérieure.

Ce guide vous montre comment scraper des données derrière des pages de connexion avec Python. Vous allez construire un petit scraper exécutable qui inspecte un formulaire de connexion, publie des identifiants via un requests.Session, transporte les cookies de session (et un token CSRF) dans des requêtes authentifiées, puis lit le contenu protégé. Nous utilisons le site de pratique public quotes.toscrape.com/login comme cible sécurisée tout au long. La section légalité proche de la fin n'est pas un boilerplate : elle fixe la règle stricte qui rend tout cela défendable, alors lisez-la avant de pointer ce code vers un vrai compte.

Ce que vous allez construire

Un script Python qui s'authentifie contre un formulaire de connexion, puis récupère une page qui ne s'affiche que pour un utilisateur connecté. En utilisant la cible de pratique comme exemple fil conducteur, le script gère chaque partie d'un vrai flux d'authentification :

• Form inspection lire les noms de champs et l'URL d'action du formulaire de connexion depuis son HTML.
• CSRF token extraire le token caché du formulaire et le rejouer à la soumission.
• Session login publier les identifiants via un requests.Session persistant.
• Cookie carry-over réutiliser la session pour que ses cookies accompagnent chaque requête ultérieure.
• Authenticated fetch demander une page protégée et confirmer que vous êtes connecté.

Pourquoi une simple requête échoue derrière une connexion

Envoyez un requests.get() brut à une page qui nécessite une connexion et vous obtenez l'une de deux non-réponses : une redirection vers le formulaire de connexion, ou le HTML de connexion lui-même avec un statut 200. Dans les deux cas, le contenu protégé n'est pas là. Le serveur verrouille la page sur une session qu'il ne voit pas, parce que votre script ne s'est jamais authentifié et n'envoie pas le cookie qui le prouve.

L'authentification est le premier mur. Le deuxième est tout ce que les sites font pour maintenir le trafic automatisé à l'écart même quand vous détenez une session valide : des tokens CSRF cachés qui changent par requête, des limites de débit, des vérifications de réputation d'IP, et des pages dont le contenu est rendu par JavaScript après le chargement plutôt qu'expédié dans le HTML initial. Un client statique ne peut pas exécuter ce JavaScript, donc même une récupération connectée peut revenir vide. Quand votre cible combine un mur de connexion avec un rendu côté client ou un blocage anti-bot, le travail difficile appartient à un service conçu pour cela, et c'est là que la Crawling API intervient plus loin.

Prérequis

Quelques éléments en place avant tout code. Aucun ne prend longtemps.

Python de base. Vous devez être à l'aise pour écrire et exécuter un script et installer des packages avec pip. Si l'analyse HTML est nouvelle pour vous, notre guide sur l'utilisation de BeautifulSoup en Python couvre ce que ce tutoriel suppose.

Python 3.8 ou supérieur. Confirmez avec python --version. Si vous ne l'avez pas, installez-le depuis python.org ou via une distribution comme Anaconda.

Des identifiants que vous êtes autorisé à utiliser. Pour le site de pratique, n'importe quel nom d'utilisateur et mot de passe fonctionnent. Pour un vrai travail, utilisez uniquement un compte que vous possédez ou que vous êtes explicitement autorisé à accéder. Ne réutilisez jamais des identifiants volés, partagés ou devinés.

Un compte Crawlbase et un token JS (pour la dernière étape). Quand votre vraie cible rend le contenu avec JavaScript ou bloque les clients ordinaires, vous routerez la requête authentifiée via la Crawling API. Inscrivez-vous, ouvrez votre tableau de bord et copiez votre token JavaScript (JS). Traitez-le comme un mot de passe et ne le mettez pas dans le contrôle de version.

Configurer le projet

Créez un environnement virtuel pour isoler les dépendances, puis installez les deux bibliothèques dont le scraper a besoin.

python --version

python -m venv login_env
source login_env/bin/activate

pip install requests beautifulsoup4

Sous Windows, activez l'environnement avec login_env\Scripts\activate au lieu de la ligne source. Deux dépendances font le travail : requests gère la session HTTP, et beautifulsoup4 analyse le formulaire de connexion pour que vous puissiez lire ses noms de champs et extraire le token CSRF.

Étape 1 : Inspecter le formulaire de connexion

Avant de pouvoir publier des identifiants, vous devez savoir exactement ce que le formulaire attend : l'URL vers laquelle il soumet, les noms de ses champs de saisie, et toutes les valeurs cachées qu'il transporte. Ouvrez la page de connexion dans votre navigateur, faites un clic droit sur le formulaire et choisissez Inspecter. Sur la cible de pratique, le formulaire publie vers /login et contient un champ username, un champ password et un champ caché csrf_token. Les vrais sites varient, alors confirmez toujours ces noms dans le HTML en direct plutôt que de supposer.

Vous pouvez lire la même structure par programme. Récupérez la page de connexion, chargez-la dans BeautifulSoup et affichez les champs du formulaire pour savoir quoi envoyer.

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"))

Exécutez ceci et vous verrez les trois noms de champs affichés, y compris le csrf_token caché. Cette valeur cachée est la pièce que la plupart des scrapers de connexion en première tentative manquent : le serveur l'émet sur la page de connexion et rejette tout POST qui ne la renvoie pas, ce qui est exactement ce qu'une défense contre la falsification de requête inter-sites est censée faire.

Étape 2 : Se connecter avec une session et le token CSRF

Publiez maintenant les identifiants. La clé est d'utiliser un objet requests.Session plutôt qu'un requests.post ponctuel. Une session persiste les cookies entre les requêtes, donc une fois que le serveur définit un cookie de session lors d'une connexion réussie, chaque requête ultérieure via cette même session envoie le cookie automatiquement et le serveur continue à vous traiter comme connecté.

Le flux est : GET la page de connexion pour recevoir un token CSRF frais (et les cookies initiaux), extraire le token du champ caché, puis POST le nom d'utilisateur, le mot de passe et ce même token vers l'URL d'action du formulaire via la session.

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.")

Exécutez le script et, lors d'une connexion réussie, vous verrez Login succeeded suivi du cookie de session que le serveur a défini. Ce cookie est votre preuve d'identité pour tout ce qui suit. Vérifier le lien Logout est un test de succès simple et fiable : ce texte n'apparaît que pour un utilisateur authentifié, donc sa présence confirme que la session a fonctionné plutôt que de se fier uniquement au code de statut.

Étape 3 : Récupérer une page protégée et l'analyser

Avec la session authentifiée, chaque requête via ce même objet session transporte le cookie de connexion automatiquement. Récupérer une page protégée est donc juste un autre session.get(), sans en-têtes supplémentaires nécessaires. Ici nous réutilisons la session de l'étape 2 pour demander une page et analyser son contenu, exactement comme vous analyseriez vos propres données exportées.

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")

Parce que la session détient le cookie, le serveur renvoie la version connectée de la page au lieu de vous rediriger vers le formulaire. Si vous substituez votre propre URL de tableau de bord autorisé et ses vrais sélecteurs, c'est le schéma complet : connectez-vous une fois, puis lisez autant de pages protégées que vous en avez besoin via la même session.

Étape 4 : Porter la session dans la Crawling API

L'approche de session simple cesse de fonctionner quand la page protégée est rendue par JavaScript, ou quand le site challenge les clients automatisés avant même que votre cookie soit vérifié. Dans ce cas, vous gardez la même connexion que vous avez construite ci-dessus et passez la requête authentifiée à la Crawling API, en transmettant les cookies que le serveur vous a donnés. L'API rend la page derrière une IP de confiance et renvoie le contenu terminé.

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])

Le paramètre cookies prend le même format key1=value1; key2=value2 qu'un navigateur envoie, c'est pourquoi nous joignons le dict de cookies de la session en une seule chaîne d'en-tête. Crawlbase transmet ces cookies avec la requête qu'il rend, donc le site traite l'appel comme connecté, puis renvoie le HTML rendu pour que vous l'analysiez avec le même code BeautifulSoup de l'étape 3. Si vous faites plusieurs appels authentifiés d'affilée et souhaitez que la session persiste entre eux, consultez la FAQ ci-dessous sur le paramètre cookies-session.

À quoi ressemble la sortie

L'exécution de session simple de l'étape 3 produit des enregistrements structurés que vous pouvez sérialiser en JSON. Avec la cible de pratique, la forme est petite et prévisible :

[
  {
    "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"
  }
]

Substituez votre tableau de bord autorisé et les champs changent, mais le principe reste le même : vous vous êtes connecté, la session a transporté votre identité, et vous avez analysé du contenu qu'une requête anonyme n'aurait jamais pu atteindre.

Gérer "se souvenir de moi" et les sessions expirées

Deux problèmes pratiques apparaissent quand vous dépassez une seule exécution. Le premier est la case "se souvenir de moi". Quand un formulaire l'offre, c'est juste un autre champ de formulaire, souvent une case à cocher nommée quelque chose comme remember. Inspectez le formulaire, et si la case correspond à une valeur, ajoutez-la à votre payload (par exemple "remember": "on"). Les sites qui l'honorent renvoient un cookie de plus longue durée, donc votre session survit entre les exécutions du script au lieu d'expirer quand vous vous arrêtez. Définissez-le uniquement quand le formulaire l'a réellement ; inventer des champs que le serveur n'attend pas peut faire échouer la connexion.

Le deuxième problème est l'expiration. Les cookies de connexion ne sont pas permanents. Ils expirent selon un minuteur, lors d'une déconnexion ailleurs, ou quand le site fait tourner les sessions. L'indice est votre scraper qui récupère soudainement la page de connexion au lieu du contenu. Gérez-le en détectant l'échec (le lien Logout a disparu, ou vous avez été redirigé vers /login) et en réexécutant le flux de connexion de l'étape 2 pour créer une nouvelle session avant de réessayer. Intégrer cette vérification dès le début vous évite de scraper silencieusement des pages de connexion pendant une heure.

Rester non bloqué

Même avec une session valide, les sites surveillent le trafic qui ne ressemble pas à un humain. Quelques habitudes maintiennent une exécution autorisée saine.

• Rythmez vos requêtes. Surcharger les pages protégées dans une boucle serrée est le moyen le plus rapide de faire signaler une session. Espacez les requêtes et ajoutez un court sleep entre elles.
• Envoyez le même token CSRF que le formulaire vous a donné. Réutiliser un token périmé, ou le sauter, est une raison courante pour laquelle un POST de connexion est rejeté. Récupérez toujours le formulaire d'abord et rejouez son token actuel.
• Surveillez les codes de statut. Une exécution qui commence à renvoyer des redirections ou des défis vous indique que la session a expiré ou que le niveau d'IP n'est plus suffisant. Ralentissez et réauthentifiez-vous plutôt que de réessayer à l'aveugle.
• Misez sur la rotation pour les cibles difficiles. Quand une seule IP continue de déclencher des vérifications, la Crawling API fait tourner des adresses résidentielles pour vous ; si vous construisez votre propre pile, le Smart AI Proxy vous donne la même rotation comme point de terminaison de substitution.

Pour le guide plus large, consultez comment scraper des sites sans être bloqué et, quand la page protégée est rendue côté client, le scraping de pages JavaScript avec Python.

Est-il légal de scraper des données derrière une connexion ?

C'est la question qui décide si tout ce qui précède est approprié à exécuter, alors soyez honnête à ce sujet avant d'écrire une ligne de code de production. La réponse courte : n'accédez qu'aux comptes et aux données que vous possédez ou êtes explicitement autorisé à accéder. Dès que vous vous connectez à un site, vous acceptez ses conditions d'utilisation, et ces conditions restreignent presque toujours l'accès automatisé. Donc vous connecter ne vous donne pas le droit de scraper ; si quoi que ce soit, cela ajoute un contrat auquel vous êtes désormais lié. Si les données ne sont pas les vôtres, obtenez une autorisation écrite avant d'automatiser contre elles.

Ce qui est fermement hors limites est la partie que ce guide n'enseigne pas. N'utilisez jamais des identifiants volés, partagés ou par force brute, et ne vous connectez jamais à un compte qui n'est pas le vôtre. Ne collectez jamais les données personnelles d'autres utilisateurs, leurs messages privés, leurs profils, ou quoi que ce soit qu'une vraie personne considérerait comme le sien. Contourner l'authentification, scraper un mur de connexion auquel vous n'avez pas été invité, ou collecter des informations personnelles n'est pas une zone grise ; cela peut enfreindre les lois sur les abus informatiques et la protection des données quelle que soit la propreté de votre code. Les techniques ici existent à une seule fin : atteindre vos propres données autorisées, comme exporter des chiffres depuis un tableau de bord que vous administrez, quand le site n'offre pas de voie plus simple.

Cette voie plus simple est généralement le bon premier arrêt. Avant de scripter une connexion, vérifiez si le service a une API officielle, une fonctionnalité d'export ou de téléchargement de données, ou une intégration OAuth. Ce sont les chemins sanctionnés que le fournisseur a construits exactement pour cela, et ils vous maintiennent du bon côté des conditions que vous avez acceptées. Tournez-vous vers le scraping de session uniquement quand aucun mécanisme officiel n'existe et que les données sont véritablement les vôtres, puis limitez la portée à ces données et rien d'autre. Si un projet a besoin d'informations qui appartiennent à d'autres personnes ou à d'autres organisations, un accord de données formel est la bonne voie, pas un script de connexion plus ingénieux.

Foire aux questions

Pourquoi une simple requête renvoie-t-elle la page de connexion au lieu de mes données ?

Parce que le serveur verrouille la page sur une session que votre script n'a jamais établie. Un requests.get() brut n'envoie aucun cookie de connexion, donc le serveur vous traite comme anonyme et renvoie une redirection vers le formulaire de connexion ou le HTML du formulaire avec un statut 200. Pour atteindre le contenu, vous devez d'abord vous authentifier puis envoyer le cookie de session avec chaque requête, ce qu'un requests.Session fait automatiquement.

Comment gérer un token CSRF dans un formulaire de connexion ?

Envoyez d'abord une requête GET à l'URL de connexion, analysez le HTML renvoyé et lisez l'entrée CSRF cachée (souvent nommée csrf_token) depuis le formulaire. Incluez cette valeur exacte dans le payload que vous publiez en retour vers l'URL de connexion. Certains sites font tourner le token par requête ou en utilisent plus d'un, alors obtenez toujours le formulaire frais et inspectez-le soigneusement plutôt que de coder en dur un token.

Que change "se souvenir de moi" dans la requête ?

C'est un champ de formulaire supplémentaire, généralement une case à cocher. Quand vous l'incluez dans votre payload POST (par exemple "remember": "on"), les sites qui l'honorent émettent un cookie de plus longue durée, donc la session survit entre les exécutions du script au lieu d'expirer quand vous vous arrêtez. N'ajoutez le champ que si le formulaire l'a réellement ; envoyer des champs que le serveur n'attend pas peut casser la connexion.

Mon scraper a commencé à renvoyer des pages de connexion en cours d'exécution. Que s'est-il passé ?

Votre cookie de session a presque certainement expiré ou a été invalidé, par un minuteur, une déconnexion ailleurs, ou le site qui fait tourner les sessions. Détectez-le (le lien Logout a disparu, ou vous avez été redirigé vers /login) et réexécutez le flux de connexion pour créer une nouvelle session avant de réessayer. Intégrer cette vérification dès le début vous évite de scraper silencieusement des pages de connexion.

Puis-je scraper le compte d'une autre personne de cette façon ?

Non. Ce guide est limité aux données que vous possédez ou êtes explicitement autorisé à accéder. Utiliser des identifiants volés, partagés ou devinés, se connecter à un compte qui n'est pas le vôtre, ou collecter les données personnelles d'autres utilisateurs est hors limites et peut enfreindre les lois sur les abus informatiques et la protection des données. Si vous avez besoin de données qui appartiennent à quelqu'un d'autre, obtenez une autorisation écrite ou utilisez un accord de données officiel.

Quand dois-je utiliser la Crawling API plutôt que les simples requests ?

Utilisez requests simple quand la page protégée est du HTML statique, comme dans la cible de pratique ici. Recourez à la Crawling API quand votre cible autorisée rend son contenu avec JavaScript ou challenge les clients automatisés. Vous gardez la même connexion que vous avez construite, puis passez les cookies de session à l'API via son paramètre cookies pour qu'elle rende derrière une IP de confiance et renvoie le contenu terminé.

IK

Ian Kalvin

Ingénieur support technique · Crawlbase

Ingénieur support technique chez Crawlbase, il écrit depuis la première ligne de ce qui casse réellement en production, sur les configurations de scraping et de proxys.

NZ

Neil Zamora

Architecte senior · Crawlbase

Architecte senior chez Crawlbase, axé sur les systèmes derrière le crawling à grande échelle : rotation de proxys, résilience anti-bot et les API qui masquent cette complexité.