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" <[email protected]> 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" <[email protected]> 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 <[email protected]> >> 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 < >>> [email protected]> 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: [email protected] >>>> 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: [email protected] >>> 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: [email protected] >> 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: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
