[SP-pm] Autenticação REST

Leonardo Ruoso leonardo at ruoso.com
Tue Mar 3 13:34:51 PST 2015 

Em 03/03/2015 18:00, "Eduardo Verissimo" <everissimo em gmail.com> escreveu:
>
> Obrigado pelo seu tempo, Leonardo!
>
> Vou dar um exemplo aqui que eu acho que pode dar alguma explicação e
sanar de vez as dúvidas.
>
> Se eu uso cookies para identificar o usuário, mas não retorno informações
específicas para ele, em "/ultimas-noticias" tudo bem. Mas se eu oferecer
uma lista de "favoritos" que é criada por ele e só por ele, digamos, em
"/favoritos" então eu estaria quebrando a especificação. Me corrija se
estiver errado.

Aí a questão é sutil. Explico:

Você pode ter os favoritos do Leonardo, e mesmo que só o Leonardo possa
ler, poderia ser /favorito/Leonardo.HTML e isso é como eu vou acessar esse
recurso, ele pode ser rest sim.

Se contudo for /favorito usado por todos os usuários e cada um obter uma
resposta diferente daí não é Rest.

> Eu não entenderia, no entanto, qual a diferença em mandar a usuário e
senha em cada request, porque, em determinado ponto do processamento, eu
teria as mesmas informações para gerar a resposta. Seria possível oferecer
os favoritos em uma url em "/usuario/:id/favoritos" também, mas só quem
tivesse autorização poderia ver os dados, ao invés de "/favoritos". Neste
último caso, a informação teria uma url única, e não mudaria por causa de
valores guardados em uma sessão - o id de usuário.

E isso conceitualmente tem uma grande diferença com muitos desdobramentos
em termos de arquitetura.

> Enfim... Só estou tentando entender esses casos pra entender melhor o
conceito (e provavelmente aplicar em alguma aplicação).

Por hora é importante guardar que cada recurso deve ter um identificador
exclusivo.

Que autenticação e autorização são ortogonais.

> Em 3 de março de 2015 07:51, Leonardo Ruoso <leonardo em ruoso.com> escreveu:
>
>>
>> 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
>> >
>>
>>
>> =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/1cfa8ac2/attachment-0001.html>

More information about the SaoPaulo-pm mailing list