On 3/1/15 9:51 PM, Eduardo Verissimo wrote:
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".
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.
Não, não e não ..... =)
Primeiro: não há controle de sessão, não no servidor.
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.
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.
Eu acho que ele quiz dizer que não há razões para se ter sessões de
usuário ...
Eu estou lendo uma explicação, na Wikipedia, do aspecto /stateless /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."
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.
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?
Obrigado!
Em 27 de fevereiro de 2015 19:17, Leonardo Ruoso <[email protected]
<mailto:[email protected]>> escreveu:
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.
O que não deve rolar numa requisição rest? Elementos de
autenticação não devem integrar path ou quest.
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.
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.
Em 27/02/2015 06:55, "Leonardo Ruoso" <[email protected]
<mailto:[email protected]>> escreveu:
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.
Em 26/02/2015 22:59, "Eduardo Verissimo" <[email protected]
<mailto:[email protected]>> escreveu:
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".
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.
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.
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.
Obrigado pela força!
Eduardo Veríssimo
Em 26 de fevereiro de 2015 20:25, Leonardo Ruoso
<[email protected] <mailto:[email protected]>> escreveu:
Autenticação Rest é Autenticação Web, simples assim.
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.
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
Em 25 de fevereiro de 2015 20:40, Eduardo Verissimo
<[email protected] <mailto:[email protected]>>
escreveu:
Olá, pessoal!
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.
Obrigado!
Eduardo Veríssimo
=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: [email protected]
<mailto:[email protected]>
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
--
Leonardo Ruoso
Journalist, Perl developer and business consultant
Media, UFC/2006; Telecom, IFCE/1998
=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: [email protected]
<mailto:[email protected]>
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: [email protected]
<mailto:[email protected]>
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: [email protected]
<mailto:[email protected]>
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: [email protected]
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
--
Eduardo Almeida - Software Engineer
[email protected] - 27 3261-0082 / 27 9839 3755
*WEB2 Solutions* - Inovando, sempre!
=begin disclaimer
Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
SaoPaulo-pm mailing list: [email protected]
L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
=end disclaimer
