<br><br><div><span class="gmail_quote">On 5/6/06, <b class="gmail_sendername">Manlio Perillo</b> <<a href="mailto:manlio_perillo@libero.it">manlio_perillo@libero.it</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
jarrod roberson ha scritto:<br>> [...]<br>><br>> an intelligent session management implementation would track be able to<br>> tell from<br>> the auth request that the user had already started a session and just
<br>> use that.<br>><br>> this kind of thing is already been written by many people, the OP needs<br>> to just use<br>> something that already exists, session tracking code is not something<br>> you should be
<br>> writting unless you are writing framework code or an app server.<br>><br>> and since he is confusing<br><br>Yes, I wrongly use the term REST protocol in place of UDP connections.<br><br>/ equating authenticaiton == sessions he lacks
<br><br>Not really.<br><br>I simply have seen an UDP protocol that uses sessions to identify each<br>request.<br>The session is obtained after an authentication phase.</blockquote><div><br>if the sesssion id never changes I am SURE you have seen an insecure UDP protocol
<br>which means unless the client and server are generating dynamic single use tokens and "know" what the next valid session id the client should send, which implies encryption plus authenticaiton on every request.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Since I think that the procedure is similar to HTTP session handling, I<br>was asking if there is some reusable support for creating "secure"
<br>session id and if cred has some support for this.</blockquote><div><br><br>you still don't understand STATE != Authentication.<br><br>ANYONE can sniff the packets, get whatever token or breadcrumb you are using for the state id and spoof it.
<br>that is unless you REQUIRE authentication on every request. "secure" session id's imply a form of authenticaiton on every request.<br><br>you can't just "encrypt" a string and call it a "secure" session id.
<br><br>you can have UNSECURE STATE tracking with out Authentication on every request, using server side sessions is just one way to do it.<br><br>you can NOT have SECURE STATE tracking without some form of authetenication on every request, that authentication might be "implied" by some encryption process, but it is still a form of authentication.
<br><br><br></div></div>