<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 2:29 PM, Yann Cointepas <span dir="ltr"><<a href="mailto:yann@cointepas.net" target="_blank">yann@cointepas.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>But, according to previous posts, I understood that signedrequest/rqlcontroller may evolve to become a replacement of Pyro/ZMQ. It means that it is necessary to find a way to make it usable for real users via an API like cubicweb.dbapi. Otherwise it would be the end of this API.<br>



<br></div>I think it should not be too hard to generate a secret token from a password. For each CWUser, such a token could be kept updated with the password on the server via hooks. The dbapi could, given the password, generate the same secret token (the contrary must be very difficult and time consuming) to use for identification. All this system could be in a specific cube named cubicweb-enableconnectionviadbapiusinghttporhttps (some people may prefer a shorter name) that would depend on signedrequest and rqlcontroller.<br>




</div><div dir="ltr"><br></div></blockquote><div><br></div><div>Yann,</div><div><br></div><div>I read examples from  signedrequest/test/unittest_authenticate.py. I understood very similarly to Dimitri.</div><div><br></div>
<div>If I understand correctly, signedrequest is used for the authentication of different devices (or different client programs). For example, define randomly one secret token for one device on the server side. Copy and save this secret token to your client program. (no more password information need to be saved in the memory in client program)</div>
<div><br></div><div>In other words, we can easily remove any device from server by removing a specified token. In the client side, there is no more  password but with an "app token" for the authentication. When we remove "app token" on the server, we don't need to remove password information on client side.</div>
<div><br></div><div>Based on this mechanism, it is not necessary to generate secret token from password. This secret token can be considered as a second password only for the machine, but not for human.</div><div><br></div>
<div>If it is wrong, please correct me.</div><div><br></div><div>Best,</div><div>Jinpeng </div></div><br></div></div>