somente comunicação de cabeçalho http? - Por favor explique

Question

A captura de tela abaixo é feita usando o firebug. O firefox < - > a comunicação do servidor da web capturada aconteceu após clicar no botão de login. Mas não vejo nenhum redirecionamento no meu firefox. Isso significa que o firefox e o servidor da web se comunicaram somente no nível de cabeçalhos http ?

Eu tenho script pronto em ruby / mechanize para obter alguns detalhes de um fórum. Eu testei / codifiquei usando o fórum vBulletin.org . Então eu consegui entrar no meu fórum de teste e felizmente mudei para finalizar o meu script usando o fórum certo. Mas eu não consigo fazer login. Meu script retorna apenas a página de login, que eu suponho que seja "tentativa de login malsucedida".

• É possível que alguém explique a imagem abaixo para mim?

  • Em particular, porque há 11 linhas? Por que não apenas um?
  • Se eu puder entender apenas o tipo de blindly/without thinking respostas para o servidor da web. Estou certo?

• o firefox envia a postagem quando clico no botão de login auth_username=myusername&auth_password=mypassword&auth_login=Login , mas meu script envia auth_username=radek&auth_password=mypassword está ok ou a &auth_login=Login deve ser apresentada?

• Existe alguma chance de simular essa comunicação, digamos, em ruby?

• ou eu estava pensando se eu posso record a comunicação e, em seguida, replay no meu script (se possível)

tela de comunicação http://i49.tinypic.com/13zcqj6.jpg

html da página de login

<form class="login" method="post"> <fieldset>
<legend>Members Login</legend> 

<div>
<label for="auth_username">Username</label> <input id="auth_username" name="auth_username">
</div>

<div>
<label for="auth_password">Password</label> <input id="auth_password" name="auth_password" type="password">
</div>

</fieldset>
<div class="buttons">
<input name="auth_login" type="submit" value="Login"><p class="note"><a href="/forgotpassword">Forgot your password?</a></p>

</div>

</form>

meu script de ruby

require 'rubygems'
require 'mechanize'
#agent = WWW::Mechanize.new

agent = WWW::Mechanize.new 

page = agent.get("http://www.vbulletin.org/forum/index.php")

login_form = page.form_with(:action => 'login.php?do=login')


puts 
login_form.fields.each { |f| puts "#{f.name} : #{f.value}" }    
login_form['vb_login_username'] = 'user name'
login_form['vb_login_password'] = ''

page = agent.submit login_form

output = File.open("login.html", "w") {|f| f.write(page.parser.to_html) }

mecanizar o log a partir da tentativa de login que não funciona

 INFO -- : Net::HTTP::Get: /login?auth_successurl=http://www.somedomain.com/forum/yota?baz_r=1
DEBUG -- : request-header: accept-language => en-us,en;q=0.5
DEBUG -- : request-header: connection => keep-alive
DEBUG -- : request-header: accept => */*
DEBUG -- : request-header: accept-encoding => gzip,identity
DEBUG -- : request-header: user-agent => WWW-Mechanize/0.9.3 (http://rubyforge.org/projects/mechanize/)
DEBUG -- : request-header: accept-charset => ISO-8859-1,utf-8;q=0.7,*;q=0.7
DEBUG -- : request-header: host => www.somedomain.com
DEBUG -- : request-header: keep-alive => 300
DEBUG -- : Read 400 bytes
DEBUG -- : Read 1424 bytes
DEBUG -- : Read 2448 bytes
DEBUG -- : Read 3211 bytes
DEBUG -- : response-header: vary => Accept-Encoding
DEBUG -- : response-header: cache-control => no-store, no-cache, must-revalidate, post-check=0, pre-check=0
DEBUG -- : response-header: connection => close
DEBUG -- : response-header: expires => Thu, 19 Nov 1981 08:52:00 GMT
DEBUG -- : response-header: content-type => text/html; charset=utf-8
DEBUG -- : response-header: date => Fri, 29 Jan 2010 23:43:12 GMT
DEBUG -- : response-header: content-encoding => gzip
DEBUG -- : response-header: server => Apache/2.2.3 (CentOS)
DEBUG -- : response-header: content-length => 3211
DEBUG -- : response-header: set-cookie => PHPSESSID=7cfilg86ju2ldcgso22246hpu4; path=/, WebStats:visitorId=lSMkcwuSWEE%3D; expires=Mon, 27-Jan-2020 23:43:12 GMT; path=/, WebStats:sessionId=%2B2HHK296t%2BQ%3D; expires=Mon, 27-Jan-2020 23:43:12 GMT; path=/
DEBUG -- : response-header: accept-ranges => bytes
DEBUG -- : response-header: pragma => no-cache
DEBUG -- : gunzip body
DEBUG -- : saved cookie: PHPSESSID=7cfilg86ju2ldcgso22246hpu4
DEBUG -- : saved cookie: WebStats:visitorId=lSMkcwuSWEE%3D
DEBUG -- : saved cookie: WebStats:sessionId=%2B2HHK296t%2BQ%3D
 INFO -- : status: 200
DEBUG -- : query: "auth_username=radek&auth_password=mypassword"
 INFO -- : Net::HTTP::Post: /login?auth_successurl=http://www.somedomain.com/forum/yota?baz_r=1
DEBUG -- : request-header: accept-language => en-us,en;q=0.5
DEBUG -- : request-header: connection => keep-alive
DEBUG -- : request-header: accept => */*
DEBUG -- : request-header: accept-encoding => gzip,identity
DEBUG -- : request-header: content-type => application/x-www-form-urlencoded
DEBUG -- : request-header: user-agent => WWW-Mechanize/0.9.3 (http://rubyforge.org/projects/mechanize/)
DEBUG -- : request-header: cookie => WebStats:sessionId=%2B2HHK296t%2BQ%3D; WebStats:visitorId=lSMkcwuSWEE%3D; PHPSESSID=7cfilg86ju2ldcgso22246hpu4
DEBUG -- : request-header: referer => http://www.somedomain.com/login?auth_successurl=http://www.somedomain.com/forum/yota?baz_r=1
DEBUG -- : request-header: accept-charset => ISO-8859-1,utf-8;q=0.7,*;q=0.7
DEBUG -- : request-header: content-length => 43
DEBUG -- : request-header: host => www.somedomain.com
DEBUG -- : request-header: keep-alive => 300
DEBUG -- : Read 650 bytes
DEBUG -- : Read 1674 bytes
DEBUG -- : Read 2698 bytes
DEBUG -- : Read 3211 bytes
DEBUG -- : response-header: vary => Accept-Encoding
DEBUG -- : response-header: cache-control => no-store, no-cache, must-revalidate, post-check=0, pre-check=0
DEBUG -- : response-header: connection => close
DEBUG -- : response-header: expires => Thu, 19 Nov 1981 08:52:00 GMT
DEBUG -- : response-header: content-type => text/html; charset=utf-8
DEBUG -- : response-header: date => Fri, 29 Jan 2010 23:43:13 GMT
DEBUG -- : response-header: content-encoding => gzip
DEBUG -- : response-header: server => Apache/2.2.3 (CentOS)
DEBUG -- : response-header: content-length => 3211
DEBUG -- : response-header: accept-ranges => bytes
DEBUG -- : response-header: pragma => no-cache
DEBUG -- : gunzip body
 INFO -- : status: 200

    

Answer 1

O redirecionamento é normalmente efetuado através dos códigos de status de resposta HTTP 301 (movido permanentemente) ou 302 (encontrado / movido temporariamente). Esses códigos de status de resposta HTTP 301 e 302 usados para realizar o redirecionamento estão incluídos nos cabeçalhos HTTP.

Só porque você não "viu nenhum redirecionamento no Firefox" não significa que o redirecionamento não estava acontecendo: foi, nos bastidores.

Existe outra maneira de redirecionar, usando JavaScript em uma página. Com o JavaScript, o redirecionamento pode ser óbvio para o usuário, onde ele pode ser mostrado primeiro e depois redirecionado (talvez após o atraso) para o outro local. Mas, esses não são redirecionamentos HTTP que viajam em virtude dos códigos de status de resposta do cabeçalho HTTP.

Para resolver sua dúvida sobre o Ruby: você deve fazer essa pergunta no Stack Overflow. Mas, em poucas palavras, sim, você deve ser capaz de definir os códigos de resposta de redirecionamento 301 e 302 com qualquer tecnologia da Web do lado do servidor.

UPDATE: Para responder à questão seguinte no seu comentário abaixo:

Se você quiser saber mais sobre como o HTTP funciona , recomendamos o seguinte livro: HTTP: O Guia Definitivo de David Gourley & Brian Totty . Você também pode consultar o padrão HTTP oficial, conforme definido por RFC 2616: Protocolo de transferência de hipertexto - HTTP / 1.1 .

Quanto ao motivo pelo qual a série de solicitações acima na sua pergunta leva 11 etapas , você precisa perguntar aos autores originais do software em questão. Provavelmente poderia ter sido implementado com menos etapas, mas provavelmente não apenas 1 passo. Considere, pelo menos, um dos redirecionamentos é necessário pelo servidor para definir um cookie no navegador do usuário antes de enviá-los para o recurso protegido.

Como você está tentando replicar um mecanismo de autenticação personalizado baseado em cookie, também sugiro que você concentre seus estudos em como esses sistemas são normalmente criados.

Se você estiver tentando fazer o script de uma página de login, verifique se o seu programa POSTs para o servidor corresponde a uma solicitação real em todos os aspectos, incluindo o parâmetro que você não está incluindo no momento.

Além disso, você precisa ter certeza de que seu código está aceitando e enviando de volta quaisquer cookies enviados pelo servidor. Não preservar os cookies enviados pelo servidor é um problema comum. erro com este tipo de exercício. Além disso, você precisa instruir qualquer biblioteca que estiver usando para comunicações HTTP para seguir os redirecionamentos. Algumas delas não seguem redirecionamentos por padrão.

E, finalmente, para depurar, capture os cabeçalhos e o corpo de solicitação e resposta, na página da Web e no programa e compare-os . Suspeite de quaisquer diferenças.