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

[Wilson MacGyver]

I looked around but didn't see any obvious ways to handle user
sessions in Misultin? I looked
around for mochiweb too and all I found was some example codes about
setting cookies manually.

The only place I've found anything that deal with session handling is
in nitrogen.

Am I missing something obvious? or is this something I need to roll my own?

Thanks

--
Omnem crede diem tibi diluxisse supremum.
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Steve Vinoski]

On Sat, Jun 4, 2011 at 11:50 AM, Wilson MacGyver <wmac...@gmail.com> wrote:
> I looked around but didn't see any obvious ways to handle user
> sessions in Misultin? I looked
> around for mochiweb too and all I found was some example codes about
> setting cookies manually.
>
> The only place I've found anything that deal with session handling is
> in nitrogen.
>
> Am I missing something obvious? or is this something I need to roll my own?

Yaws?

http://yaws.hyber.org/session.yaws

--steve

[Max Lapshin]

Why do you want to store session at server?
It is really a bad idea, which should be avoided if possible. Rails
has switched to cookie stored sessions long time ago and this method
brings
excelent scalability and convenience.

Server storage for sessions is a very complicated thing.

[Wilson MacGyver]

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.

Steve,

Thanks for the pointer to yaws. I'll look at that direction.

Thanks

On Sat, Jun 4, 2011 at 1:44 PM, Max Lapshin <max.l...@gmail.com> wrote:
> Why do you want to store session at server?
> It is really a bad idea, which should be avoided if possible.  Rails
> has switched to cookie stored sessions long time ago and this method
> brings
> excelent scalability and convenience.
>
> Server storage for sessions is a very complicated thing.
>

--

Omnem crede diem tibi diluxisse supremum.

[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.l...@gmail.com> wrote:

On Sat, Jun 4, 2011 at 10:15 PM, Wilson MacGyver <wmac...@gmail.com> 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?

[Tobias]

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...@gmail.com> 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...@gmail.com> wrote:

>
>
>
> > On Sat, Jun 4, 2011 at 10:15 PM, Wilson MacGyver <wmacgy...@gmail.com> 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...@erlang.orghttp://erlang.org/mailman/listinfo/erlang-questions

[Wilson MacGyver]

Perfect! Thank you very much.

[Roberto Ostinelli]

2011/6/4 Wilson MacGyver <wmac...@gmail.com>

I looked around but didn't see any obvious ways to handle user
sessions in Misultin? I looked
around for mochiweb too and all I found was some example codes about
setting cookies manually.

The only place I've found anything that deal with session handling is
in nitrogen.

Am I missing something obvious? or is this something I need to roll my own?

Thanks

 

there are several arguments for and against server session variables. let's however not forget that http is a stateless protocol, and that this is yet-again-another-http-hack, together with comet applications and such.

the reason why i've not added those in misultin is because there are several good ways to deal with them, like memcached for instance. i just believe that sessions are not something http-related, and thus not within a lightweight http library.

just my opinion, of course. :)

r.

[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...@gmail.com> 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...@gmail.com> wrote:

>
>
>
>
>
>
>
> > On Sat, Jun 4, 2011 at 10:15 PM, Wilson MacGyver <wmacgy...@gmail.com> 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...@erlang.orghttp://erlang.org/mailman/listinfo/erlang-questions

[Wilson MacGyver]

On Sun, Jun 5, 2011 at 6:00 AM, Roberto Ostinelli <rob...@widetag.com> wrote:
> there are several arguments for and against server session variables. let's
> however not forget that http is a stateless protocol, and that this is
> yet-again-another-http-hack, together with comet applications and such.

Yup, the industry spent 15 years putting state into a stateless protocol :)

[Wilson MacGyver]

Thanks for the suggestion, that is worth exploring too.

On Sun, Jun 5, 2011 at 7:36 AM, zambal <zam...@gmail.com> wrote:
> Depending on your requirements, a nice solution could be spawning a
> process per session and store the data in an Erlang process.
>
>
> Gr, Vincent
>

--
Omnem crede diem tibi diluxisse supremum.

[Roberto Ostinelli]

2011/6/5 Wilson MacGyver <wmac...@gmail.com>

On Sun, Jun 5, 2011 at 6:00 AM, Roberto Ostinelli <rob...@widetag.com> wrote:
> there are several arguments for and against server session variables. let's
> however not forget that http is a stateless protocol, and that this is
> yet-again-another-http-hack, together with comet applications and such.

Yup, the industry spent 15 years putting state into a stateless protocol :)

indeed :) my point was merely related to why there are not in misultin itself.

it might get, though, who knows :)

r.