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 <leona...@ruoso.com> escreveu: > > Em 01/03/2015 21:51, "Eduardo Verissimo" <everiss...@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 <leona...@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" <leona...@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" <everiss...@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 <leona...@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 < > everiss...@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@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@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@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@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@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@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@pm.org L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer