[Cascavel-pm] HTTP_REFERER - variável de ambiente não funciona no protocolo https

fernandolouis em terra.com.br fernandolouis em terra.com.br
Sexta Maio 16 13:00:54 PDT 2008


Entendi em partes...

Posso então usar utilizar um função de espalhamento como a md5_hex do 
Digest:MD5 para
criar esse token... beleza, até aí tudo bem...

Só não entendi o seguinte:

exemplo
Site A: autorizado a linkar
Site B: não autorizado

Se o site A linkar para 
http://www.meu-servidor.com/auth/get_auth_token?partner=76b142499e2ac8795f6623256bfe0e42
então vou olhar no DB de onde está vindo o clique (através do 
$input{partnet} e então criar um identificado de sessão caso exista esse 
$input{partnet}.

Mas o site B pode fazer o mesmo link e meu get_auth_token.pl igualmente vai 
aceitar pq o $input{partner} vai estar correto.

Não entendi como "um qualquer" não poderá compiar a url de um site 
autorizado e  usar no site dele, não iria funcionar.

[]s
Fernando



----- Original Message ----- 
From: "Nilson Santos Figueiredo Junior" <acid06 em gmail.com>
To: "Cascavel Perl Mongers" <cascavel-pm em pm.org>
Sent: Friday, May 16, 2008 3:57 PM
Subject: Re: [Cascavel-pm]HTTP_REFERER - variável de ambiente não funciona 
no protocolo https


2008/5/16  <fernandolouis em terra.com.br>:
> Alguma dica para eu pesquisar referente a webservices e token?

Um token de autorização é simplesmente um número ou uma cadeira de
caracteres ou... bem, o que você quiser que seja, desde que seja
grande o suficiente (pelo menos uns 128bits) para garantir provável
uniqueness (unicidade? existe essa palavra?).

Se você quer algo bem simples, basta definir um protocolo qualquer.
Por exemplo, um servidor autorizado, ao invés de referenciar
diretamente o seu site, faz um link para um script redirecionador
neste mesmo servidor autorizado. Este script redirecionador contacta o
seu servidor, por exemplo, faz uma requisição para:

  http://www.seu-servidor.com/auth/get_auth_token?partner=76b142499e2ac8795f6623256bfe0e42

Onde cada um dos sites parceiros terá um "partner token" diferente.

Seu servidor, após possíveis validações (por exemplo, você pode
associar um "partnet token" ao endereço IP do servidor parceiro, caso
isto faça sentido em seu caso), responde este request com um token de
autorização gerado por algum mecanismo qualquer à sua escolha, por
exemplo. ele irá responder isto:

  dd932543e3da27049c51b0f3e225b666

E salvar este token algum lugar como um token válido
(preferencialmente, expirável dentro de N minutos).

Aí então, o script redirecionador no servidor autorizado, redireciona
o cliente original para, por exemplo, utilizando o token acima:

  http://www.seu-servidor.com/auth/validate_auth_token?token=dd932543e3da27049c51b0f3e225b666

Seu servidor então irá verificar a validade do token fornecido e,
então, liberar o acesso para o usuário, caso o token seja válido.

Esta é uma das formas mais simples que eu posso pensar. A sua API de
autorização poderia ser bem mais complexa, com uma interface via
WebServices, por exemplo. Eu particularmente odeio WebServices, mas
isso é outra discussão.

-Nilson Santos F. Jr.
_______________________________________________
Cascavel-pm mailing list
Cascavel-pm em pm.org
http://mail.pm.org/mailman/listinfo/cascavel-pm



Mais detalhes sobre a lista de discussão Cascavel-pm