なぜcurlとwgetは403 forbiddenという結果になるのでしょうか？

ファイルを wget と curl でダウンロードしようとすると、403エラー（forbidden）で拒否されます。

同じマシンのウェブブラウザを使ってファイルを見ることができます。

http://www.whatsmyuseragent.com で取得したブラウザのユーザーエージェントで再試行します。私はこうしています。

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

と

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

が、やはり禁止されています。他にどのような理由で403になるのでしょうか？また、それを克服するために wget と curl コマンドをどのように変更すればよいのでしょうか？

(これは、ファイルを取得できるかどうかではなく、ブラウザから保存できることを知っているからです。）

更新

この質問に対して素晴らしい回答をしてくださった方々に感謝します。私が遭遇した具体的な問題は、サーバーがリファラーをチェックしていることでした。コマンドラインにこれを追加することで、私は curl と wget を使用してファイルを取得することができました。

リファラーをチェックするサーバーは、全くチェックを行わない別の場所に302でバウンスするため、そのサイトの curl や wget はきれいに動作しました。

もし興味があれば、これは私が埋め込みCSSについて学ぶためにこのページを読んでいて、例としてこのサイトのCSSを見ようとしたことから起こったことです'。私が困っていた実際のURLはthisで、私が最終的に得たcurlは次の通りです。

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

で、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

とても興味深いです。

starfry
編集された質問 29日 6月 2014 в 8:58
UnixとLinux
curl wget
28日 6月 2014 в 7:06
560 ビュー
質問へのコメント (2)
ソリューション

HTTPリクエストには、curlやwgetで設定されていないヘッダが含まれる場合があります。例えば

  • クッキー：これはリクエストが拒否される最も可能性の高い理由であり、私はダウンロードサイトでこのようなことが起こるのを見たことがあります。クッキー key=val が与えられた場合、 curl の -b key=val (または --cookie key=val) オプションで設定することができます。
  • Referer (sic): ウェブページのリンクをクリックすると、ほとんどのブラウザは現在のページをリファラーとして送信する傾向があります。これは当てになりませんが、eBayでさえ、このヘッダがない場合、パスワードのリセットに失敗しています。ですから、はい、それは起こるかもしれません。このための curl オプションは、-e URL と --referer URL です。
  • 認証: ユーザー名/パスワードダイアログの制御不能なUIのため、今ではあまり使われなくなってきていますが、まだ可能性はあります。curlで-u user:password(または--user user:password`) オプションで設定することができます。
  • User-Agent: いくつかのリクエストでは、ユーザーエージェントによって異なるレスポンスが返されます。これは良い意味でも悪い意味でも使うことができます(ミラーのリストではなく、実際のダウンロードを提供します)。

通常、ブラウザの開発者ツール（FirefoxとChromeはこれをサポートしています）を使用して、ブラウザから送信されたヘッダを読み取ることができます。接続が暗号化されていない場合（つまり、HTTPSを使用していない場合）、Wiresharkのようなパケットスニッファーを使用して、この目的を達成することも可能です。

これらのヘッダ以外にも、ウェブサイトは裏で何らかのアクションを起こし、状態を変化させることがあります。たとえば、ページを開くときに、バックグラウンドでダウンロードリンクを用意するためのリクエストが実行される可能性があります。あるいは、ページ上でリダイレクトが行われることもあります。これらのアクションは通常、Javascriptを使用しますが、これらのアクションを容易にするために隠しフレームが存在する場合もあります。

ダウンロードサイトから簡単にファイルを取得する方法をお探しなら、plowshareに含まれるplowdownをご覧ください。

Lekensteyn
編集した答え 29日 6月 2014 в 7:49
解説 (3)

上記の回答に補足すると、Chromeのデベロッパーツール（v26.0以降）およびFirebug（v1.12）にある "Copy as cURL" 機能を使用することが可能です。この機能は、ネットワークタブのリクエスト行を右クリックすることで利用できます。

解説 (2)

上記をすべて試しましたが、運がありませんでした。ユーザーエージェント文字列を取得するためにdevブラウザツールを使用しました。以下を追加すると、成功します。

--user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"
garethTheRed
編集した答え 6日 7月 2016 в 6:09
解説 (0)

何を求めているかにもよりますが、それはクッキーかもしれません。 Firefoxの場合、問題のページで右クリックし、"ページ情報を見る"を実行します。セキュリティ]アイコンを選択し、[Cookieを表示]ボタンをクリックします。

クッキーを調べるには、Firefoxのプラグイン「Live HTTP Headers」が欠かせません。どのようなクッキーが設定され、どのようなクッキーがウェブサーバーに送り返されるかを見ることができます。

wgetはクッキーで動作しますが、クッキーを送信しなかったというヒントを与えないので、全く腹立たしいものです'。最善の策は、あなたのブラウザから関連するクッキーをすべて削除し、最初のログインやページ閲覧の手順を踏むことです。 クッキーとPOSTまたはGETパラメータがあるかどうか、HTTPヘッダを調べてみてください。最初のログインステップをwgetで "--keep-session-cookies" と "-save-cookies" オプションを使って行ってみてください。そうすると、テキストエディタで見ることができるクッキーファイルができます。次のステップでは、そのクッキーファイルを使ってwget --load-cookies` を使ってください。

解説 (3)

これが起こり得るもう1つの理由は、サイトにSSLが必要な場合です。ブラウザは自動的にHTTPからHTTPSに転送されますが、カールとウィゲットは転送されません。 したがって、HTTPの代わりにHTTPSを使用してリクエストを試してください。

解説 (1)