<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 3/2/15 9:41 AM, Marcelo Milhomem
wrote:<br>
</div>
<blockquote
cite="mid:21145889-DEE8-44BA-81BF-4EA31C0F9521@is4web.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="">Enviar o ID do usuário em toda requisição é ruim,
ele acaba sendo redundante e fazendo par com o token.</div>
</blockquote>
Sim e não. Eu apenas quiz citar exemplos.<br>
<blockquote
cite="mid:21145889-DEE8-44BA-81BF-4EA31C0F9521@is4web.com"
type="cite">
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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. </div>
</blockquote>
<br>
<blockquote
cite="mid:21145889-DEE8-44BA-81BF-4EA31C0F9521@is4web.com"
type="cite">
<div class="">Um tópico importante citado por outros é que o seu
método de autenticação tem que ser suportado largamente</div>
</blockquote>
quando sua API é pública.<br>
<blockquote
cite="mid:21145889-DEE8-44BA-81BF-4EA31C0F9521@is4web.com"
type="cite">
<div class=""> 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.</div>
<div class=""><br class="">
</div>
<div class="">Abs,</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Mar 1, 2015, at 11:46 PM, Eduardo Almeida
<<a moz-do-not-send="true"
href="mailto:eduardo@web2solutions.com.br" class="">eduardo@web2solutions.com.br</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">On 3/1/15 11:34 PM, Eduardo
Almeida wrote:<br class="">
</div>
<blockquote
cite="mid:54F3CC4F.9080701@web2solutions.com.br"
type="cite" class="">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.</blockquote>
Dá para se implementar coisas interessantes sobre os
tokens.<br class="">
<br class="">
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.<br class="">
<br class="">
Por exemplo<br class="">
<br class="">
- você pode associar um 'user id' (geralmente eu
envio, via headers, o id do user que está chamando o end
point)<br class="">
- você pode associar uma 'allowed origin' (e negar
requisições com esse token se feita de uma origem
desconhecida)<br class="">
<br class="">
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.<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<div class="moz-signature">-- <br class="">
Eduardo Almeida - Software Engineer<br class="">
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:eduardo@web2solutions.com.br">eduardo@web2solutions.com.br</a>
- 27 3261-0082 / 27 9839 3755<br class="">
<br class="">
<b class="">WEB2 Solutions</b> - Inovando, sempre! <br
class="">
<span
id="cid:part1.08090807.03010902@web2solutions.com.br"><dhtmlx_certified.png></span></div>
</div>
=begin disclaimer<br class="">
Sao Paulo Perl Mongers: <a moz-do-not-send="true"
href="http://sao-paulo.pm.org/" class="">http://sao-paulo.pm.org/</a><br
class="">
SaoPaulo-pm mailing list: <a moz-do-not-send="true"
href="mailto:SaoPaulo-pm@pm.org" class="">SaoPaulo-pm@pm.org</a><br
class="">
L<<a moz-do-not-send="true"
href="http://mail.pm.org/mailman/listinfo/saopaulo-pm"
class="">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br
class="">
=end disclaimer<br class="">
</div>
</blockquote>
</div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">=begin disclaimer
Sao Paulo Perl Mongers: <a class="moz-txt-link-freetext" href="http://sao-paulo.pm.org/">http://sao-paulo.pm.org/</a>
SaoPaulo-pm mailing list: <a class="moz-txt-link-abbreviated" href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a>
L<a class="moz-txt-link-rfc2396E" href="http://mail.pm.org/mailman/listinfo/saopaulo-pm"><http://mail.pm.org/mailman/listinfo/saopaulo-pm></a>
=end disclaimer
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
Eduardo Almeida - Software Engineer<br>
<a class="moz-txt-link-abbreviated" href="mailto:eduardo@web2solutions.com.br">eduardo@web2solutions.com.br</a> - 27 3261-0082 / 27 9839 3755<br>
<br>
<b>WEB2 Solutions</b> - Inovando, sempre!
<br>
<img src="cid:part6.00000500.01080906@web2solutions.com.br"></div>
</body>
</html>