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

[Wilson MacGyver]

Perfect! Thank you very much.

On Jun 4, 2011, at 4:47 PM, Tobias <tobias.rodaebel@REDACTED> wrote:

> Hi Wilson,
> 
> Jacob Vorreuter from Heroku has a straightforward implementation of an
> Erlang Redis client. See http://github.com/JacobVorreuter/redo for
> further details. And this http://github.com/JacobVorreuter/redis_pool
> is another one.
> 
> I would go for storing session IDs in cookies and keep all session
> data in Redis with an appropriate expiration time.
> 
> Kind regards,
> Tobias
> 
> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions