
<html><body bgcolor="#FFFFFF"><div>For the type of system I work on </div><div>"<span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: 'PT Serif', Georgia, 'DejaVu Serif', 'Bitstream Vera Serif', 'Times New Roman', serif; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); font-size: 24px; line-height: 32px; "> a 1000-byte cookie adds 16ms to the response time of a single request made over a broadband <span class="caps">DSL</span> connection</span><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: 'PT Serif', Georgia, 'DejaVu Serif', 'Bitstream Vera Serif', 'Times New Roman', serif; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><font class="Apple-style-span" size="6"><span class="Apple-style-span" style="font-size: 20px; line-height: 18px;">"</span></font></span><br><br></div><div>That alone could be a deal breaker.</div><div><br></div><div>Your assertion of 99% time people only put userid in</div><div>cookie store hasn't been my experience. </div><div><br></div><div>And serverside session need not be in db. Memcached</div><div>and redis are common solutions in high traffic site.</div><div>Redis even supports autoexpire.</div><div><br></div><div>It may just be we have very different usage case. But I think</div><div>claiming cookiestore is the solution 100% of the time is a </div><div>over statement.</div><div><br></div><div>On Jun 4, 2011, at 2:39 PM, Max Lapshin <<a href="mailto:max.lapshin@gmail.com">max.lapshin@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><span>On Sat, Jun 4, 2011 at 10:15 PM, Wilson MacGyver <<a href="mailto:wmacgyver@gmail.com">wmacgyver@gmail.com</a>> wrote:</span><br><blockquote type="cite"><span>storing sessions on server has been a very common practice, esp due to cookie</span><br></blockquote><blockquote type="cite"><span>has a limit of 4K on the browser side. Not to mention most cookie</span><br></blockquote><blockquote type="cite"><span>store I've seen,</span><br></blockquote><blockquote type="cite"><span>store data in plain text. There is also the overhead of cookie read</span><br></blockquote><blockquote type="cite"><span>from browser esp if you</span><br></blockquote><blockquote type="cite"><span>are working on high traffic site. thus, the session hash id set it</span><br></blockquote><blockquote type="cite"><span>cookies that points to server</span><br></blockquote><blockquote type="cite"><span>data is the common practice.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span><a href="http://wonko.com/post/why-you-probably-shouldnt-use-cookies-to-store-session-data">http://wonko.com/post/why-you-probably-shouldnt-use-cookies-to-store-session-data</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>but regardless of where is stored, the question is really about are</span><br></blockquote><blockquote type="cite"><span>there any modules</span><br></blockquote><blockquote type="cite"><span>that exists for handling user sessions.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>I haven't found anything serious in that text. Just "don't do it".</span><br><span></span><br><span>1) In 99% times you need to store only user_id in session. Nothing</span><br><span>more. There is no secret in this information</span><br><span>2) It is absoulutely ok to send data plaintext in cookies.</span><br><span>3) Cookies are signed, so server just verify if cookie is not broken.</span><br><span>4) It doesn't differ: either client send you some magic "user_id" or</span><br><span>"session_id". Difference is only in storing these sessions.</span><br><span>User records doesn't expire, but sessions expire and you _have_ to track them.</span><br><span></span><br><span></span><br><span>Worsest problem in server session storage is that you need to expire</span><br><span>them and delete.</span><br><span>Second problem is that you need to share them across servers.</span><br><span>Server session store doesn't differ from database and still User</span><br><span>record _must_ be fetched on each request or you will be required to</span><br><span>maintain coherence between database and session storage.</span><br><span></span><br><span></span><br><span>So, server storage:</span><br><span>1) has no benefits</span><br><span>2) is a very complicated mechanism</span><br><span>3) add one more database select (because session storage is a</span><br><span>database) on each request.</span><br><span>4) make scaling harder</span><br><span></span><br><span>Without any profits. What for do you advise it?</span><br></div></blockquote></body></html>