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

[zambal]

Depending on your requirements, a nice solution could be spawning a
process per session and store the data in an Erlang process.


Gr, Vincent

On Jun 4, 10:07 pm, Wilson MacGyver <wmacgy...@REDACTED> wrote:
> 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.laps...@REDACTED> wrote:
>
>
>
>
>
>
>
> > On Sat, Jun 4, 2011 at 10:15 PM, Wilson MacGyver <wmacgy...@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-...
>
> >> 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?
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@REDACTED://erlang.org/mailman/listinfo/erlang-questions