<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 3/1/15 9:51 PM, Eduardo Verissimo
wrote:<br>
</div>
<blockquote
cite="mid:CAB3BPP5STFOmK6==MJxsx4tSt_67s2BBtPSRT6urC9BskaoE3g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Eu fiquei com um pouco de dúvidas a respeito da última
frase, "não parece haver motivo para que uma sessão de
usuário seja um objeto restful".<br>
<br>
</div>
Então, deixe-me ver se entendi: o usuário faz login e é criada
uma sessão para que o servidor saiba quem está na outra ponta
da conexão. As requisições, então, através do cookie, passam a
identidade do usuário, que é obtida da sessão que é guardada
no servidor.<br>
</div>
</div>
</blockquote>
<br>
Não, não e não ..... =)<br>
<br>
Primeiro: não há controle de sessão, não no servidor.<br>
<br>
Segundo: A manipulação de cookies em requisições CORS é algo bem
chato quando e abre o leque de browsers que irão ser usados (espero
que sua API suporte clients JS). O uso de cookie é completamente
desnecessário.<br>
<br>
<br>
Terceiro: cada requisição REST envia ao servidor todas as informções
necessárias para que tal ação seja processada. Não há uma
necessidade de se realizar autenticação em cada requisição. O que
muito se vê é o seguinte: O user autentica o client uma primeira vez
e recebe um token para as consecutivas requisições feita á API.
Tokens expiram. É lógico que você pode definir a vida útil deles de
acordo com sua necessidade. É uma boa prática, no ato da
autenticação, notificar seu client sobre quando o token irá expirar,
isso por exemplo, permitirá o end user, saber quando é necessário
autenticar a app novamente.<br>
<br>
<br>
Eu acho que ele quiz dizer que não há razões para se ter sessões de
usuário ...<br>
<br>
<br>
<blockquote
cite="mid:CAB3BPP5STFOmK6==MJxsx4tSt_67s2BBtPSRT6urC9BskaoE3g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Eu estou lendo uma explicação, na Wikipedia, do aspecto <i>stateless
</i>do REST: "The client–server communication is further
constrained by no client context being stored on the server
between requests. Each request from any client contains all
the information necessary to service the request, and session
state is held in the client. The session state can be
transferred by the server to another service such as a
database to maintain a persistent state for a period and allow
authentication."<br>
<br>
</div>
<div>Então guardar dados do usuário em uma sessão no servidor
não quebra o stateless? Eu imaginava que sim, pois uma parte
dos dados que o servidor usaria para fazer o processamento já
estaria disponível localmente, e não seria necessário retirar
essas informações do request.<br>
<br>
</div>
<div>Por outro lado, eu poderia considerar que o id da sessão
que vem com o cookie seria a mesma coisa que passar usuário e
senha todas as vezes em que for requisitada a informação.
Imagino que seja isso que você está afirmando, não?<br>
<br>
</div>
<div>Obrigado!</div>
<div><br>
<br>
</div>
<div>
<div>
<div><br>
<br>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Em 27 de fevereiro de 2015 19:17,
Leonardo Ruoso <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>></span>
escreveu:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Eu não quis responder da primeira vez sem reler
e confirmar a questão e ver se alguém relevante tinha
escrito algo contrário, mas fato é que autenticação e
autorização são questões ortogonais ao resto, tanto é que
fazem parte da coreografia de acesso às páginas web,
conteúdo restful, desde sempre.</p>
<p dir="ltr">O que não deve rolar numa requisição rest?
Elementos de autenticação não devem integrar path ou
quest. </p>
<p dir="ltr">O que seria ideal? Que o mecanismo fosse
suportado pelo maior número de clientes e que possa ser
integrado a mecanismos de autenticação existentes, o mundo
enterprise exige isso, mas o consumer lida melhor com
oauth2.</p>
<p dir="ltr">De qualquer forma, o que vale explicar, é que a
autenticação não é parte de um recurso, é ortogonal a ele,
e não parece haver motivo para que uma sessão de usuário
seja um objeto restful. É um caso patente de RPC.</p>
<div class="gmail_quote">Em 27/02/2015 06:55, "Leonardo
Ruoso" <<a moz-do-not-send="true"
href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>>
escreveu:
<div>
<div class="h5"><br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Eu preciso estudar melhor para lhe
prover uma resposta adequada, mas a identificação
do usuário, seja mantida através de cookie, seja
de certificados, parece-me ortogonal ao recurso.</p>
<div class="gmail_quote">Em 26/02/2015 22:59,
"Eduardo Verissimo" <<a moz-do-not-send="true"
href="mailto:everissimo@gmail.com"
target="_blank">everissimo@gmail.com</a>>
escreveu:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Leonardo, eu costumo usar o
Store:DBIx::Class com Catalyst.
Mas junto uso o
Session::State::Cookie, e uso de
uma maneira que me parece
inadequada se quiser conformidade
com REST. Justamente por causa do
"Session".<br>
</div>
<br>
</div>
O que eu gostaria de fazer neste
momento é, durante a autenticação,
gerar um par de chaves, mandar a
pública para o cliente e então receber
a informação de identificação
criptografada, evitando assim guardar
informações em sessões no servidor com
os dados do usuário. Eu não sei se é a
melhor forma de fazer isso, e posso
estar falando besteira.<br>
<br>
</div>
Renato, estou dando uma olhada em seu
código. Eu escrevi um código para fazer
login com Facebook, mas acho que seu
código está bem melhor implementado que
o meu. Há uma diferença,
particularmente: eu gravo as informações
do usuário em uma sessão, e acho que
isso faz com que haja alguma vantagem no
tempo de acesso. Mas isso não é REST,
então não vem ao caso.<br>
<br>
</div>
Outra coisa: acho que também vale a pena
criar algum tipo de cache para acelerar a
obtenção dos dados do usuário no servidor.
Me parece fazer sentido, mas ainda preciso
investigar mais essa ideia.<br>
<br>
</div>
Obrigado pela força!<br>
<br>
</div>
Eduardo Veríssimo<br>
<div>
<div>
<div>
<div><br>
<br>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Em 26 de fevereiro de
2015 20:25, Leonardo Ruoso <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:leonardo@ruoso.com"
target="_blank">leonardo@ruoso.com</a>></span>
escreveu:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr">Autenticação Rest é
Autenticação Web, simples assim.<br>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Se é algo
«crítico»: OpenLDAP+Kerberos ou
ApacheDS. Tente adotar um esquema de
ampla utilização, assim a maioria dos
softwares a serem integrados terão
suporte nativo/plugin disponível.<br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Se é algo «não
crítico»:
Catalyst::Plugin::Authentication …
Store::DBix::Class. É o mais comum,
que está disponível no tutorial do
Catalyst. Catalyst::Tutorial::Manual<br>
<br>
<div class="gmail_quote">Em 25 de
fevereiro de 2015 20:40, Eduardo
Verissimo <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:everissimo@gmail.com"
target="_blank">everissimo@gmail.com</a>></span>
escreveu:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div>
<div dir="ltr">
<div>
<div>
<div>Olá, pessoal!<br>
<br>
</div>
De que maneira vocês
estão tratando
autenticação de
aplicações REST? Estou
procurando alguma coisa
pronta para Catalyst, e
não encontrei nada
pronto.<br>
<br>
</div>
Obrigado!<br>
<br>
</div>
Eduardo Veríssimo<br>
</div>
<br>
</div>
</div>
<span>=begin disclaimer<br>
Sao Paulo Perl Mongers: <a
moz-do-not-send="true"
href="http://sao-paulo.pm.org/"
target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a
moz-do-not-send="true"
href="mailto:SaoPaulo-pm@pm.org"
target="_blank">SaoPaulo-pm@pm.org</a><br>
L<<a moz-do-not-send="true"
href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br>
</span></blockquote>
</div>
<span><font color="#888888"><br>
<br clear="all">
<br>
-- <br>
<div>Leonardo Ruoso
<div>Journalist, Perl developer
and business consultant<br>
<div>Media, UFC/2006; Telecom,
IFCE/1998</div>
</div>
</div>
</font></span></div>
</div>
<br>
=begin disclaimer<br>
Sao Paulo Perl Mongers: <a
moz-do-not-send="true"
href="http://sao-paulo.pm.org/"
target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a
moz-do-not-send="true"
href="mailto:SaoPaulo-pm@pm.org"
target="_blank">SaoPaulo-pm@pm.org</a><br>
L<<a moz-do-not-send="true"
href="http://mail.pm.org/mailman/listinfo/saopaulo-pm"
target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
=begin disclaimer<br>
Sao Paulo Perl Mongers: <a
moz-do-not-send="true"
href="http://sao-paulo.pm.org/"
target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a
moz-do-not-send="true"
href="mailto:SaoPaulo-pm@pm.org"
target="_blank">SaoPaulo-pm@pm.org</a><br>
L<<a moz-do-not-send="true"
href="http://mail.pm.org/mailman/listinfo/saopaulo-pm"
target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
<br>
=begin disclaimer<br>
Sao Paulo Perl Mongers: <a moz-do-not-send="true"
href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a moz-do-not-send="true"
href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
L<<a moz-do-not-send="true"
href="http://mail.pm.org/mailman/listinfo/saopaulo-pm"
target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">=begin disclaimer
Sao Paulo Perl Mongers: <a class="moz-txt-link-freetext" href="http://sao-paulo.pm.org/">http://sao-paulo.pm.org/</a>
SaoPaulo-pm mailing list: <a class="moz-txt-link-abbreviated" href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a>
L<a class="moz-txt-link-rfc2396E" href="http://mail.pm.org/mailman/listinfo/saopaulo-pm"><http://mail.pm.org/mailman/listinfo/saopaulo-pm></a>
=end disclaimer
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
Eduardo Almeida - Software Engineer<br>
<a class="moz-txt-link-abbreviated" href="mailto:eduardo@web2solutions.com.br">eduardo@web2solutions.com.br</a> - 27 3261-0082 / 27 9839 3755<br>
<br>
<b>WEB2 Solutions</b> - Inovando, sempre!
<br>
<img src="cid:part18.06040906.08080404@web2solutions.com.br"></div>
</body>
</html>