[SP-pm] Autenticação REST

[Leonardo Ruoso]

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
>>
>>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150227/6b8bf99b/attachment.html>