[SP-pm] Autenticação REST

Sun Mar 1 16:51:27 PST 2015

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.

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>
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> 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> 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>
>>> 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> 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
>>>>>  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
>>>>  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
>>>
>>>
> =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
>
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150301/62ec71f6/attachment-0001.html>