[SP-pm] Autenticação REST

Tue Mar 3 13:00:02 PST 2015

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.

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.

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

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