[SP-pm] Autenticação REST
Eduardo Almeida
eduardo at web2solutions.com.br
Sun Mar 1 18:34:55 PST 2015
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 <leonardo em ruoso.com
> <mailto:leonardo em ruoso.com>> 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" <leonardo em ruoso.com
> <mailto:leonardo em ruoso.com>> 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" <everissimo em gmail.com
> <mailto:everissimo em gmail.com>> 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
> <leonardo em ruoso.com <mailto:leonardo em ruoso.com>> 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
> <everissimo em gmail.com <mailto:everissimo em gmail.com>>
> 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: SaoPaulo-pm em pm.org
> <mailto:SaoPaulo-pm em pm.org>
> 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: SaoPaulo-pm em pm.org
> <mailto:SaoPaulo-pm em pm.org>
> 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: SaoPaulo-pm em pm.org
> <mailto:SaoPaulo-pm em pm.org>
> 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: SaoPaulo-pm em pm.org
> <mailto:SaoPaulo-pm em pm.org>
> 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: SaoPaulo-pm em pm.org
> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
--
Eduardo Almeida - Software Engineer
eduardo em web2solutions.com.br - 27 3261-0082 / 27 9839 3755
*WEB2 Solutions* - Inovando, sempre!
-------------- Pr?xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150301/e9645968/attachment-0001.html>
-------------- Pr?xima Parte ----------
Um anexo n?o-texto foi limpo...
Nome: dhtmlx_certified.png
Tipo: image/png
Tamanho: 11630 bytes
Descri??o: n?o dispon?vel
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150301/e9645968/attachment-0001.png>
More information about the SaoPaulo-pm
mailing list