perché curl e wget porterebbe a un 403 proibito?

Provo a scaricare un file con wgete curlviene rifiutato con un errore 403 (vietato).

Posso visualizzare il file utilizzando il browser Web sulla stessa macchina.

Riprovo con l'agente utente del mio browser, ottenuto da http://www.whatsmyuseragent.com . Lo faccio:

wget -U 'Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0' http://...

e

curl -A 'Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0' http://...

ma è ancora proibito. Quali altri motivi potrebbero esserci per il 403, e quali modi posso modificare i comandi wgete curlper superarli?

(non si tratta di poter ottenere il file - so che posso semplicemente salvarlo dal mio browser; si tratta di capire perché gli strumenti da riga di comando funzionano in modo diverso)

aggiornare

Grazie a tutte le eccellenti risposte fornite a questa domanda. Il problema specifico che avevo riscontrato era che il server stava controllando il referrer. Aggiungendo questo alla riga di comando ho potuto ottenere il file usando curle wget.

Il server che ha verificato il referrer è rimbalzato attraverso un 302 in un'altra posizione che non ha eseguito alcun controllo, quindi uno curlo wgetquel sito ha funzionato in modo pulito.

Se qualcuno è interessato, questo è accaduto perché stavo leggendo questa pagina per conoscere i CSS incorporati e stavo provando a guardare i CSS del sito per un esempio. L'URL effettivo con cui ho avuto problemi era questo e l' curlho finito con

curl -L -H 'Referer: http://css-tricks.com/forums/topic/font-face-in-base64-is-cross-browser-compatible/' http://cloud.typography.com/610186/691184/css/fonts.css

e il wget è

 wget --referer='http://css-tricks.com/forums/topic/font-face-in-base64-is-cross-browser-compatible/' http://cloud.typography.com/610186/691184/css/fonts.css

Molto interessante.

Una richiesta HTTP può contenere più intestazioni che non sono impostate da curl o wget. Per esempio:

• Cookie: questo è il motivo più probabile del rifiuto di una richiesta, l'ho visto accadere sui siti di download. Dato un cookie key=val, è possibile impostarlo con l' opzione -b key=val(o --cookie key=val) per curl.
• Referer (sic): quando si fa clic su un collegamento in una pagina Web, la maggior parte dei browser tende a inviare la pagina corrente come referrer. Non bisogna fare affidamento, ma anche eBay non è riuscito a reimpostare una password quando questa intestazione era assente. Quindi sì, può succedere. L' curlopzione per questo è -e URLe --referer URL.
• Autorizzazione: ora sta diventando meno popolare a causa dell'interfaccia utente incontrollabile della finestra di dialogo nome utente / password, ma è ancora possibile. Può essere impostato curlcon l' opzione -u user:password(o --user user:password).
• User-Agent: alcune richieste genereranno risposte diverse a seconda dell'agente utente. Questo può essere usato in modo positivo (fornendo il download reale anziché un elenco di mirror) o in modo errato (rifiuta i programmi utente che non iniziano con Mozilla, o contengono Wgeto curl).

Normalmente puoi usare gli strumenti per sviluppatori del tuo browser (Firefox e Chrome supportano questo) per leggere le intestazioni inviate dal tuo browser. Se la connessione non è crittografata (ovvero non utilizza HTTPS), è possibile utilizzare anche uno sniffer di pacchetti come Wireshark per questo scopo.

Oltre a queste intestazioni, i siti Web possono anche innescare alcune azioni dietro le quinte che cambiano stato. Ad esempio, quando si apre una pagina, è possibile che venga eseguita una richiesta in background per preparare il collegamento per il download. Oppure si verifica un reindirizzamento sulla pagina. Queste azioni in genere utilizzano Javascript, ma potrebbe anche esserci un frame nascosto per facilitare queste azioni.

Se siete alla ricerca di un metodo per recuperare facilmente i file da un sito di download, dare un'occhiata a plowdown, incluso con vomere .

Voglio solo aggiungere alle risposte di cui sopra che potresti utilizzare la funzione "Copia come cURL" presente negli strumenti di sviluppo di Chrome (dalla v26.0) e Firebug (dalla v1.12 ). È possibile accedere a questa funzione facendo clic con il pulsante destro del mouse sulla riga della richiesta nella scheda Rete.

Ho provato tutto quanto sopra senza fortuna; utilizzato lo strumento browser dev per ottenere la stringa user-agent, una volta aggiunto il seguente successo:

--user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"

A seconda di ciò che stai chiedendo, potrebbe essere un cookie. Con Firefox, puoi fare clic con il tasto destro del mouse sulla pagina in questione, "Visualizza informazioni sulla pagina". Scegli l'icona "Sicurezza", quindi fai clic sul pulsante "Visualizza cookie".

Per sconcertare i cookie, il plug-in "Live HTTP Headers" di Firefox è essenziale. Puoi vedere quali cookie vengono impostati e quali cookie vengono inviati al server Web.

wgetpuò funzionare con i cookie, ma è totalmente esasperante, in quanto non suggerisce che non abbia inviato cookie. La soluzione migliore è rimuovere tutti i cookie correlati dal browser e seguire la sequenza di accesso iniziale o visualizzazione della pagina richiesta. Guarda "Intestazioni HTTP in tempo reale" per i cookie e per eventuali parametri POST o GET. Fai il primo passo di accesso wgetusando le opzioni "--keep-session-cookies" e "--save-cookies". Questo ti darà un file cookie che puoi guardare con un editor di testo. Utilizzare wget --load-cookiescon il file cookie per i passaggi successivi.

Un altro motivo per cui ciò può accadere è se il sito richiede SSL. Il browser passerà automaticamente da HTTP a HTTPS, ma curl e wget no. Quindi prova la richiesta con HTTPS anziché HTTP.