por que curl e wget resultariam em um 403 proibido?

Question

Eu tento baixar um arquivo com wget e curl e ele é rejeitado com um erro 403 (proibido).

Eu posso ver o arquivo usando o navegador da web na mesma máquina.

Eu tento novamente com o agente de usuário do meu navegador, obtido pelo link . Eu faço isso:

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://...

mas ainda é proibido. Quais outras razões podem existir para o 403, e de quais maneiras eu posso alterar os comandos wget e curl para superá-los?

(não se trata de conseguir o arquivo - sei que posso salvá-lo do meu navegador; é sobre entender por que as ferramentas de linha de comando funcionam de maneira diferente)

atualização

Obrigado a todas as excelentes respostas dadas a esta pergunta. O problema específico que encontrei foi que o servidor estava verificando o referenciador. Adicionando isso à linha de comando, consegui obter o arquivo usando curl e wget .

O servidor que verificou o referenciador retornou por meio de um 302 para outro local que não realizou verificações, portanto, um curl ou wget desse site funcionou corretamente.

Se alguém estiver interessado, isso aconteceu porque eu estava lendo esta página para aprender sobre o CSS incorporado e estava tentando analisar o css do site para um exemplo. O URL real com o qual eu estava tendo problemas era e o curl com o qual acabei

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 o 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

Muito interessante.

    

Answer 1

Uma solicitação HTTP pode conter mais cabeçalhos que não são definidos por curl ou wget. Por exemplo:

• Cookie: esse é o motivo mais provável pelo qual uma solicitação seria rejeitada. Vi isso acontecer em sites de download. Dado um cookie key=val , você pode configurá-lo com a opção -b key=val (ou --cookie key=val ) para curl .
• Referer (sic): ao clicar em um link em uma página da web, a maioria dos navegadores tende a enviar a página atual como referenciadora. Não deve ser invocado, mas mesmo eBay não conseguiu redefinir uma senha quando este cabeçalho estava ausente. Então sim, isso pode acontecer. A opção curl para isso é -e URL e --referer URL .
• Autorização: isso está se tornando menos popular agora devido à interface do usuário incontrolável da caixa de diálogo nome de usuário / senha, mas ainda é possível. Pode ser definido em curl com a opção -u user:password (ou --user user:password ).
• User-Agent: algumas solicitações geram respostas diferentes, dependendo do agente do usuário. Isso pode ser usado de uma maneira boa (fornecendo o download real em vez de uma lista de espelhos) ou de maneira ruim (rejeite os agentes do usuário que não iniciam com Mozilla ou contenham Wget ou curl ). / li>

Normalmente, você pode usar as ferramentas do desenvolvedor do seu navegador (o Firefox e o Chrome suportam isso) para ler os cabeçalhos enviados pelo seu navegador. Se a conexão não estiver criptografada (ou seja, não estiver usando HTTPS), você também poderá usar um sniffer de pacotes como o Wireshark para essa finalidade.

Além desses cabeçalhos, os sites também podem acionar algumas ações nos bastidores que mudam de estado. Por exemplo, ao abrir uma página, é possível que uma solicitação seja executada no segundo plano para preparar o link de download. Ou um redirecionamento acontece na página. Essas ações normalmente usam JavaScript, mas também pode haver um quadro oculto para facilitar essas ações.

Se você estiver procurando um método para buscar facilmente arquivos de um site de download, dê uma olhada no plowdown, incluído no plowshare .

    

Answer 2

Só quero adicionar às respostas acima que você pode usar o recurso "Copiar como cURL" presente nas ferramentas do desenvolvedor do Chrome (desde v26.0) e no Firebug (desde v1.12 ). Você pode acessar este recurso clicando com o botão direito do mouse na linha de solicitação na guia Rede.

    

Answer 3

Tentei todos os itens acima, mas sem sorte; usei a ferramenta de navegador dev para obter a string user-agent, uma vez que adicionei o seguinte, sucesso:

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

    

Answer 4

Dependendo do que você está pedindo, pode ser um cookie. Com o Firefox, você pode clicar com o botão direito do mouse quando estiver na página em questão, "Exibir informações da página". Escolha o ícone "Segurança" e clique no botão "Visualizar cookies".

Para confundir cookies, o plug-in "HTTP HTTP Headers" do Firefox é essencial. Você pode ver quais cookies são definidos e quais cookies são enviados de volta para o servidor da Web.

wget pode funcionar com cookies, mas é totalmente irritante, já que não dá a menor dica de que não enviou cookies. Sua melhor aposta é remover todos os cookies relacionados do seu navegador e passar por qualquer login inicial ou sequência de visualização da página necessária. Consulte "Cabeçalhos HTTP ativos" para cookies e para qualquer parâmetro POST ou GET. Faça a primeira etapa de login com wget usando as opções "--keep-session-cookies" e "--save-cookies". Isso lhe dará um arquivo de cookie que você pode olhar com um editor de texto. Use wget --load-cookies com o arquivo de cookie para as próximas etapas.

    

Answer 5

Outra razão pela qual isso pode acontecer é se o site exigir SSL. Seu navegador encaminhará automaticamente do HTTP para o HTTPS, mas o curl e o wget não. Portanto, tente a solicitação com HTTPS em vez de HTTP.