Skip to main content
Molte pagine utili sono accessibili soltanto dopo l’accesso: dashboard degli account, portali interni, directory dei membri, ricerche salvate, cronologie degli ordini e report privati. Dal punto di vista di un web scraper, il problema non consiste soltanto nell‘“inserire nome utente e password”. La vera attività consiste nel mantenere una sessione autenticata valida abbastanza a lungo da navigare ed estrarre i dati in modo affidabile. Lo scraping autenticato deve essere limitato ai dati ai quali si è autorizzati ad accedere. L’accesso non elimina gli obblighi legali, contrattuali, di privacy o relativi alle politiche della piattaforma. Consideralo un flusso di lavoro a rischio maggiore: usa account autorizzati, rispetta i controlli di accesso ed evita di raccogliere dati non compresi nelle autorizzazioni previste per l’account.

​
Che cosa cambia dopo l’accesso

Una pagina pubblica può spesso essere recuperata con una normale richiesta HTTP. Una pagina autenticata dipende generalmente da diversi elementi dello stato del browser:
  • Cookie di sessione che dimostrano che l’utente è già autenticato.
  • Token CSRF o intestazioni delle richieste che il sito si aspetta negli invii dei moduli e nelle chiamate API.
  • Valori di archiviazione locale o di sessione usati dalle applicazioni a pagina singola.
  • Logica di reindirizzamento che rimanda i visitatori non autenticati a /login.
  • Regole di scadenza che invalidano le sessioni in seguito al trascorrere del tempo, all’inattività, a cambiamenti di IP o a eventi di sicurezza.
Per questo, copiare un URL autenticato in un web scraper spesso non funziona. L’URL è soltanto la parte visibile; è lo stato della sessione a consentire il caricamento della pagina. L’approccio più comune consiste nell’accedere una volta, salvare i Cookie ottenuti e riutilizzarli nelle esecuzioni di scraping successive. Funziona bene quando il sito mantiene attive le sessioni per ore o giorni e non le vincola troppo strettamente a un dispositivo o indirizzo IP. Nel codice, il modello è il seguente:
In produzione, non inserire i Cookie direttamente nei file sorgente. Conservali in modo sicuro, sostituiscili quando scadono e trattali come credenziali. Il riutilizzo dei Cookie è particolarmente efficace quando le pagine di destinazione sono perlopiù renderizzate lato server o quando l’API sottostante accetta gli stessi Cookie di sessione del browser. Diventa fragile quando il sito usa token di breve durata, controlli del dispositivo o richieste frequenti di riautenticazione.

​
Approccio 2: accedere con un browser

Alcuni siti richiedono un flusso di accesso in un browser reale. Il web scraper apre la pagina di accesso, compila il modulo, lo invia, attende la pagina dell’account e quindi salva lo stato del browser per le esecuzioni successive.
Le esecuzioni successive possono caricare lo stato salvato:
L’accesso tramite browser è più lento delle sole richieste basate sui Cookie, ma gestisce in modo più affidabile pagine di accesso ricche di JavaScript, reindirizzamenti e valori di archiviazione.

​
Approccio 3: riprodurre l’API di accesso

Talvolta il modulo di accesso invia una semplice richiesta POST a un endpoint di autenticazione. Se il flusso è semplice e consentito dai termini del sito, è possibile riprodurre direttamente la richiesta con un client HTTP, acquisire i Cookie risultanti e proseguire nel sito. In genere questo metodo è meno stabile dell’accesso tramite browser, perché i flussi di autenticazione spesso includono token CSRF, controlli anti-bot, fingerprinting del dispositivo o campi nascosti che cambiano. L’esame della scheda Network permette di capire se l’accesso è abbastanza semplice da riprodurre o se una sessione browser è la scelta più sicura.

​
MFA, SSO e richieste di sicurezza

L’autenticazione a più fattori modifica la progettazione. Un web scraper non deve tentare di aggirare l’MFA. Occorre invece progettare il flusso tenendone conto:
  • Usa una fase di accesso con intervento umano, quindi salva la sessione autenticata.
  • Preferisci API ufficiali o account di servizio quando il sito li mette a disposizione.
  • Prevedi la scadenza delle sessioni e crea un flusso di aggiornamento o nuovo accesso.
  • Evita di usare account personali per attività di produzione non presidiate.
I flussi Single Sign-On possono essere ancora più vincolanti, perché possono attraversare più domini, imporre politiche dell’organizzazione o attivare richieste di sicurezza quando cambia l’identità del browser. In questi casi, un profilo browser persistente o un’integrazione ufficiale sono solitamente più affidabili di un semplice client HTTP.

​
Sicurezza della sessione

Se gestito con leggerezza, lo scraping autenticato può bloccare gli account, attivare avvisi o esporre dati sensibili. Adotta queste misure di protezione:
  • Separa gli account per attività. Non mescolare attività di scraping non correlate nella stessa sessione autenticata.
  • Mantieni stabili l’IP e l’identità del browser nella stessa sessione. Cambiare Proxy durante la sessione può sembrare un tentativo di acquisizione dell’account.
  • Limita la frequenza delle azioni. Le aree autenticate sono spesso sottoposte a controlli più rigorosi delle pagine pubbliche.
  • Rileva le pagine di disconnessione. Un web scraper deve riconoscere quando è stato reindirizzato alla pagina di accesso, anziché interpretarla come dati reali.
  • Conserva i segreti in modo sicuro. Credenziali, Cookie e file di stato dell’archiviazione sono tutti sensibili.
  • Registra gli accessi in modo intenzionale. Mantieni una cronologia delle esecuzioni sufficiente a diagnosticare gli errori, ma evita di scrivere nei log contenuti privati delle pagine o credenziali.

​
Il ruolo di Octoparse

Gli strumenti di scraping visuale gestiscono generalmente le pagine autenticate in due modi: permettono all’utente di accedere tramite un browser integrato e conservano i Cookie e la sessione risultanti, oppure simulano i passaggi di accesso come parte dell’attività, affinché il web scraper possa autenticarsi prima di iniziare l’estrazione. Octoparse segue questo modello generale. Per i siti in grado di mantenere l’accesso, gli utenti possono autenticarsi nel Browser integrato e riutilizzare Cookie e sessione salvati tra le esecuzioni. Per i siti che richiedono ogni volta un nuovo flusso di accesso, l’attività può simulare il comportamento di login prima di passare alle pagine di destinazione. Restano gli stessi limiti pratici: l’MFA può richiedere l’intervento umano, le sessioni possono scadere e l’account deve essere autorizzato ad accedere ai dati raccolti.

​
Quando non eseguire lo scraping dietro un accesso

Non eseguire lo scraping di contenuti autenticati quando non disponi dell’autorizzazione, quando i dati appartengono ad altri utenti, quando i termini del sito vietano il caso d’uso o quando esiste un’esportazione o un’API ufficiale che rappresenta il canale appropriato. Lo scraping autenticato dovrebbe essere riservato a flussi di lavoro autorizzati, nei quali il titolare dell’account raccoglie i propri dati accessibili o opera nell’ambito di un processo aziendale approvato. Lo schema tecnico è semplice: autenticarsi, conservare lo stato della sessione, navigare, rilevare la scadenza e aggiornare quando necessario. La parte difficile è farlo in modo responsabile.