[SP-pm] Autenticação REST

Leonardo Ruoso leonardo at ruoso.com
Tue Mar 3 02:51:57 PST 2015


Em 01/03/2015 21:51, "Eduardo Verissimo" <everissimo em gmail.com> escreveu:
>
> 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".

Uma sessão de usuário é um objeto transiente e privado. Normalmente é
identificada por um único identificador.

A situação em que uma sessão é um atributo do objeto rest é naqueles
atributos modified_by ou created_by. Normalmente escritas pelo servidor.

> 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.

Ok

>As requisições, então, através do cookie, passam a identidade do usuário,
que é obtida da sessão que é guardada no servidor.

Num modelo de autenticação baseado em cookie ou header isso é verdadeiro.
Importa que a sessão não seja parte do path, ou da querystring.

> 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"

(Num outro momento precisamos conversar sobre o quão formidável a Wikipedia
é para nos introduziu assuntos de domínios para os quais somos alienígenas.)

>
> Então guardar dados do usuário em uma sessão no servidor não quebra o
stateles.

Aí vai depender se o seu serviço é Rest ou não. Se for uma chamada RPC que
usa a sessão para entregar qualquer conteúdo específico para o usuário,
como um feed de notícias personalizado, por exemplo, não é rest, é RPC e
somente RPC.

> 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.

Provavelmente vamos endereçar isso melhor em nossa documentação Rest, mas
aqui precisamos separar bem os conceitos...

Pense em documentos HTML num servidor WEB que você usa HTTP para ler e
manter. A autenticação é HTTP Digest. Tudo que você faz é GET, PUT e PATCH
para alterar esses documentos. Você coloca links de uma página para outra e
seus usuários não precisam de saber nada sobre sua estrutura de diretórios
para navegar e encontrar o que precisam. Não precisam saber suas categorias
ou saber que categorias correspondem a /cat/$cat_slug para navegar e não
terão problemas se você, eles não precisam dispor de informações (meta)
sobre o seu repositório para navegar por ele e não devem "quebrar" se você
incluir outras taxionomias. Simplesmente tem novos links para seguir.

>
> 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, nao?

Sim, de fato é o que HTTP BASIC auto faz, mas é um ótimo exemplo também,
pois trocando o BASIC por Digest ou por X 509 não alteraria em nada o seu
conteúdo Web, demonstrando novamente a ortogonalidade.
>
> 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
>>
>
>
> =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/20150303/c1b22243/attachment-0001.html>


More information about the SaoPaulo-pm mailing list