[erlang-questions] Handling user sessions in Misultin or any http server?

[Wilson MacGyver]

For the type of system I work on 
" a 1000-byte cookie adds 16ms to the response time of a single request made over a broadband DSL connection"

That alone could be a deal breaker.

Your assertion of 99% time people only put userid in
cookie store hasn't been my experience. 

And serverside session need not be in db. Memcached
and redis are common solutions in high traffic site.
Redis even supports autoexpire.

It may just be we have very different usage case. But I think
claiming cookiestore is the solution 100% of the time is a 
over statement.

On Jun 4, 2011, at 2:39 PM, Max Lapshin <max.lapshin@REDACTED> wrote:

> On Sat, Jun 4, 2011 at 10:15 PM, Wilson MacGyver <wmacgyver@REDACTED> wrote:
>> storing sessions on server has been a very common practice, esp due to cookie
>> has a limit of 4K on the browser side. Not to mention most cookie
>> store I've seen,
>> store data in plain text. There is also the overhead of cookie read
>> from browser esp if you
>> are working on high traffic site. thus, the session hash id set it
>> cookies that points to server
>> data is the common practice.
>> 
>> http://wonko.com/post/why-you-probably-shouldnt-use-cookies-to-store-session-data
>> 
>> but regardless of where is stored, the question is really about are
>> there any modules
>> that exists for handling user sessions.
>> 
> 
> I haven't found anything serious in that text. Just "don't do it".
> 
> 1) In 99% times you need to store only user_id in session. Nothing
> more. There is no secret in this information
> 2) It is absoulutely ok to send data plaintext in cookies.
> 3) Cookies are signed, so server just verify if cookie is not broken.
> 4) It doesn't differ: either client send you some magic "user_id" or
> "session_id". Difference is only in storing these sessions.
> User records doesn't expire, but sessions expire and you _have_ to track them.
> 
> 
> Worsest problem in server session storage is that you need to expire
> them and delete.
> Second problem is that you need to share them across servers.
> Server session store doesn't differ from database and still User
> record _must_ be fetched on each request or you will be required to
> maintain coherence between database and session storage.
> 
> 
> So, server storage:
> 1) has no benefits
> 2) is a very complicated mechanism
> 3) add one more database select (because session storage is a
> database) on each request.
> 4) make scaling harder
> 
> Without any profits. What for do you advise it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110604/2de99541/attachment.htm>