<p dir="ltr"><br>
Em 03/03/2015 18:00, "Eduardo Verissimo" <<a href="mailto:everissimo@gmail.com">everissimo@gmail.com</a>> escreveu:<br>
><br>
> Obrigado pelo seu tempo, Leonardo!<br>
><br>
> Vou dar um exemplo aqui que eu acho que pode dar alguma explicação e sanar de vez as dúvidas.<br>
><br>
> 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.</p>
<p dir="ltr">Aí a questão é sutil. Explico:</p>
<p dir="ltr">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. </p>
<p dir="ltr">Se contudo for /favorito usado por todos os usuários e cada um obter uma resposta diferente daí não é Rest.<br></p>
<p dir="ltr">> 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.</p>
<p dir="ltr">E isso conceitualmente tem uma grande diferença com muitos desdobramentos em termos de arquitetura.</p>
<p dir="ltr">> Enfim... Só estou tentando entender esses casos pra entender melhor o conceito (e provavelmente aplicar em alguma aplicação).</p>
<p dir="ltr">Por hora é importante guardar que cada recurso deve ter um identificador exclusivo.</p>
<p dir="ltr">Que autenticação e autorização são ortogonais.</p>
<p dir="ltr">> Em 3 de março de 2015 07:51, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>> escreveu:<br>
><br>
>><br>
>> Em 01/03/2015 21:51, "Eduardo Verissimo" <<a href="mailto:everissimo@gmail.com">everissimo@gmail.com</a>> escreveu:<br>
>> ><br>
>> > 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".<br>
>><br>
>> Uma sessão de usuário é um objeto transiente e privado. Normalmente é identificada por um único identificador.<br>
>><br>
>> A situação em que uma sessão é um atributo do objeto rest é naqueles atributos modified_by ou created_by. Normalmente escritas pelo servidor.<br>
>><br>
>> > 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.<br>
>><br>
>> Ok<br>
>><br>
>> >As requisições, então, através do cookie, passam a identidade do usuário, que é obtida da sessão que é guardada no servidor.<br>
>><br>
>> 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.<br>
>><br>
>> > 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"<br>
>><br>
>> (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.)<br>
>><br>
>> ><br>
>> > Então guardar dados do usuário em uma sessão no servidor não quebra o stateles.<br>
>><br>
>> 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.<br>
>><br>
>> > 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.<br>
>><br>
>> Provavelmente vamos endereçar isso melhor em nossa documentação Rest, mas aqui precisamos separar bem os conceitos...<br>
>><br>
>> 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. <br>
>><br>
>> ><br>
>> > 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?<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> ><br>
>> > Obrigado!<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > Em 27 de fevereiro de 2015 19:17, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>> escreveu:<br>
>> ><br>
>> >> 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.<br>
>> >><br>
>> >> O que não deve rolar numa requisição rest? Elementos de autenticação não devem integrar path ou quest.<br>
>> >><br>
>> >> 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.<br>
>> >><br>
>> >> 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.<br>
>> >><br>
>> >> Em 27/02/2015 06:55, "Leonardo Ruoso" <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>> escreveu:<br>
>> >><br>
>> >>> 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.<br>
>> >>><br>
>> >>> Em 26/02/2015 22:59, "Eduardo Verissimo" <<a href="mailto:everissimo@gmail.com">everissimo@gmail.com</a>> escreveu:<br>
>> >>>><br>
>> >>>> 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".<br>
>> >>>><br>
>> >>>> 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.<br>
>> >>>><br>
>> >>>> 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.<br>
>> >>>><br>
>> >>>> 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.<br>
>> >>>><br>
>> >>>> Obrigado pela força!<br>
>> >>>><br>
>> >>>> Eduardo Veríssimo<br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> Em 26 de fevereiro de 2015 20:25, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>> escreveu:<br>
>> >>>>><br>
>> >>>>> Autenticação Rest é Autenticação Web, simples assim.<br>
>> >>>>><br>
>> >>>>> 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.<br>
>> >>>>><br>
>> >>>>> 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<br>
>> >>>>><br>
>> >>>>> Em 25 de fevereiro de 2015 20:40, Eduardo Verissimo <<a href="mailto:everissimo@gmail.com">everissimo@gmail.com</a>> escreveu:<br>
>> >>>>>><br>
>> >>>>>> Olá, pessoal!<br>
>> >>>>>><br>
>> >>>>>> 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.<br>
>> >>>>>><br>
>> >>>>>> Obrigado!<br>
>> >>>>>><br>
>> >>>>>> Eduardo Veríssimo<br>
>> >>>>>><br>
>> >>>>>> =begin disclaimer<br>
>> >>>>>> Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/">http://sao-paulo.pm.org/</a><br>
>> >>>>>> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>> >>>>>> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>> >>>>>> =end disclaimer<br>
>> >>>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> -- <br>
>> >>>>> Leonardo Ruoso<br>
>> >>>>> Journalist, Perl developer and business consultant<br>
>> >>>>> Media, UFC/2006; Telecom, IFCE/1998<br>
>> >>>>><br>
>> >>>>> =begin disclaimer<br>
>> >>>>> Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/">http://sao-paulo.pm.org/</a><br>
>> >>>>> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>> >>>>> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>> >>>>> =end disclaimer<br>
>> >>>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> =begin disclaimer<br>
>> >>>> Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/">http://sao-paulo.pm.org/</a><br>
>> >>>> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>> >>>> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>> >>>> =end disclaimer<br>
>> >>>><br>
>> >><br>
>> >> =begin disclaimer<br>
>> >> Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/">http://sao-paulo.pm.org/</a><br>
>> >> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>> >> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>> >> =end disclaimer<br>
>> >><br>
>> ><br>
>> ><br>
>> > =begin disclaimer<br>
>> > Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/">http://sao-paulo.pm.org/</a><br>
>> > SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>> > L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>> > =end disclaimer<br>
>> ><br>
>><br>
>><br>
>> =begin disclaimer<br>
>> Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/">http://sao-paulo.pm.org/</a><br>
>> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
>> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
>> =end disclaimer<br>
>><br>
><br>
><br>
> =begin disclaimer<br>
> Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/">http://sao-paulo.pm.org/</a><br>
> SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
> L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
> =end disclaimer<br>
><br>
</p>