<div>You've already gotten some good answers; however, having worked extensively with this myself, I recommend:</div><div> </div><div>1) Use HTTPS for all traffic. Computers are fast. Crypto is cheap. Cookie theft is a reality on open channels.</div>
<div> </div><div>2) Use Basic-auth over HTTP -- this sends name and password, base-64-encoded.</div><div> </div><div>3) HTTP is stateless. The auth will be sent with each and every request. The fact that HTTP/1.1 allows you to keep the physical TCP connection open and send another request is purely an optimization; you cannot assume anything about the next request that comes in. In fact, a HTTP gateway may multiplex multiple internal users to a single external connection, and send different credentials (including no credentials) with each request.</div>
<div> </div><div>The stateless nature of HTTP is what makes it scale really, really well for certain problem domains and usage patterns. It's also what makes it a pain in the butt when certain kinds of efficiencies are important. This area is fraught with more distress than you would normally think. I believe this is because old-school networking people sometimes haven't yet realized the benefits of HTTP as currently implemented and optimized; meanwhile, web-only people often don't understand that there are cases where HTTP is NOT the right solution. Sitting in the middle is fun and frustrating at the same time ;-)</div>
<div> </div><div>Sincerely,</div><div> </div><div>jw</div><div><br clear="all"><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br></div><div class="gmail_quote">On Thu, Jul 7, 2011 at 12:29 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>></span> wrote:<br><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
Slightly off topic. But I want to make an erlang web site.<br>
<br>
1) How does web authentication work?<br>
<br>
Let's assume something like:<br>
<br>
   <a href="http://en.wikipedia.org/wiki/Digest_access_authentication" target="_blank">http://en.wikipedia.org/wiki/Digest_access_authentication</a><br>
<br>
This is easy to understand.<br>
<br>
What I don't understand is what happens if the session socket is closed.<br>
Handshaking tales place over an open socket and the client is<br>
authenticated - this<br>
is easy to understand.<br>
<br>
What happens if the socket is closed, and reopened in a subsequent request?<br>
Does the server set and receive a session cookie? Does the client remember and<br>
replay the authentication protocol?<br>
<br>
How does this work?<br>
<br>
2) I want to make a web thing that requires the user to authenticate themself.<br>
<br>
Should I:<br>
<br>
    a) Roll my own (some MD5 + cookies should do the job)<br>
    b) Implement  <a href="http://en.wikipedia.org/wiki/Digest_access_authentication" target="_blank">http://en.wikipedia.org/wiki/Digest_access_authentication</a><br>
    c) Something else?<br>
<br>
Seems like for a real web site there is a lot of cruft involved<br>
preventing spammers,<br>
false-accounts, forgotten-passwords etc. can I get all of this for<br>
free by getting<br>
authentication credentials via goole/facebook or something? Is this<br>
what OpenID does?<br>
<br>
Finally is this entire authentication-user management-forgot my<br>
password built-in<br>
to any of the popular erlang web servers?<br>
<br>
Cheers<br>
<br>
/Joe<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br>