A autenticação é ortogonal ao resource. Vou tentar elaborar melhor depois, mas o que está rolando é uma confusão. Em 02/03/2015 09:50, "Eduardo Almeida" <edua...@web2solutions.com.br> escreveu:
> On 3/2/15 9:41 AM, Marcelo Milhomem wrote: > > Enviar o ID do usuário em toda requisição é ruim, ele acaba sendo > redundante e fazendo par com o token. > > Sim e não. Eu apenas quiz citar exemplos. > > > O token é uma string única, randômica e temporária associada a um > usuário e persistida em algum database. É enviado em toda requisição > através de header normalmente. É uma pratica bem comum e viável. > > A questão do certificado no client é uma coisa que quero muito fazer a > um tempo, mas realmente temos poucas ferramentas prontas, temos que fazer. > O Renato falou que o HTTPS já faz isso e ficou a impressão de que isso > seria uma camada a mais e não é, ele é o próprio SSL do HTTPS, você só muda > as chaves que estão em jogo. > > A grande vantagem disso é que não precisa ter um banco de dados central > de tokens, ou um controlador de autenticação que deve ser consultado a cada > requisição. O client não mandaria mais um token e sim sua identificação > confiável por qualquer servidor HTTP que consiga resolver SSL. Você só > precisaria distribuir nesses servidores uma chave CA. > > Com essa abordagem a quantidade de requisições em banco de dados pode > cair pela metade e tira da sua arquitetura o ponto único de falha. > > > Um tópico importante citado por outros é que o seu método de > autenticação tem que ser suportado largamente > > quando sua API é pública. > > e esse método é nativo para os Browsers e muito bem documentado, eu só vi > algumas limitações no mundo Mobile quando se tenta usar um Certificado > auto-assinado. > > Abs, > > On Mar 1, 2015, at 11:46 PM, Eduardo Almeida < > edua...@web2solutions.com.br> wrote: > > On 3/1/15 11:34 PM, Eduardo Almeida wrote: > > O user autentica o client uma primeira vez e recebe um token para as > consecutivas requisições feita á API. Tokens expiram. É lógico que você > pode definir a vida útil deles de acordo com sua necessidade. > > Dá para se implementar coisas interessantes sobre os tokens. > > O token pode conter informações associadas que poderão ser usadas para > confrontar com informações obtidas sobre o cliente em cada requisição. > > Por exemplo > > - você pode associar um 'user id' (geralmente eu envio, via headers, o > id do user que está chamando o end point) > - você pode associar uma 'allowed origin' (e negar requisições com > esse token se feita de uma origem desconhecida) > > Enfim ... há uma série de coisas que poderão ser implementadas no sentido > de validar o acesso. é óbvio que há coisas que podem ser burladas quando > feita a requisição (mascarando), porém, pra burlar isso, a pessoa precisa > conhecer todo seu esquema de validação. > > > > > -- > Eduardo Almeida - Software Engineer > edua...@web2solutions.com.br - 27 3261-0082 / 27 9839 3755 > > *WEB2 Solutions* - Inovando, sempre! > <dhtmlx_certified.png> > =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> > <http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > > > > -- > Eduardo Almeida - Software Engineer > edua...@web2solutions.com.br - 27 3261-0082 / 27 9839 3755 > > *WEB2 Solutions* - Inovando, sempre! > > =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
