put_session/3 vs conn.assigns

[alonein...@gmail.com]

Please excuse me if the followings are dumb questions. I am entirely new to not only Phoenix and Elixir, but also web development.

1) When put_session/3 is used, are session data stored on server side or client side by default?

The section on "Sessions" of Phoenix's user's guide does not give any explicit answer. It says that the default storage method is "Plug's cookie session storage", while "Phoenix also supports server-side sessions via ETS" but"We don’t recommend using this store in production".

As the term "cookie" is used in the former and the adjective "server-side" is mentioned only in the ETS storage, I'm confused and I wonder if "cookie session storage" means storing session data on a cookie that is sent to the client side.

2) What is the lifetime of a Phoenix connection (I mean the "conn" thing)?

3) When should I put data inside conn.assigns and when should I use put_session/3 ? In chapter 6 of Programming Phoenix (which Chris McCord coauthors) there is an example of user authentication. The authenticated user is stored in conn.assigns.current_user . Is there any good reason not to store this in session data?

[Peter Hamilton]

1) Cookie session storage means that all the session data is stored in the cookie and encrypted (or at least signed) to prevent tampering. Alternatives are server based sessions, where usually a cookie is set with a session ID and all the data is stored on the server. Cookie based sessions are much easier to scale since you don't have to share data between multiple backend in a load balancer, drive all the data is included in each request via the cookie. Cookies are in practice bounded size wise and require a lot of redundant data transfer and parsing. As stated, prefer cookie sessions unless you really can't use them.

2) Life cycle of a connection is effectively a single request.

3) The general practice is to store things you need across requests in the session, but early in the connections lifecycle you pull the data out and put it in connection assigns. In the case of an authed user, you would store the user ID in the session and immediately use it to retrieve the full user object and store the full user object in Conn assigns. Then, for the rest of the request you can access it in its entirety. So again, store the essentials in session and then use them to populate Conn assigns.

--
You received this message because you are subscribed to the Google Groups "phoenix-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenix-talk...@googlegroups.com.
To post to this group, send email to phoeni...@googlegroups.com.
Visit this group at https://groups.google.com/group/phoenix-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/phoenix-talk/7e34e056-f5ca-4b4e-962f-c4014dc68be5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[alonein...@gmail.com]

Thank you very much. I understand 2) and 3) now.

On Wednesday, June 29, 2016 at 11:55:58 AM UTC+8, Peter Hamilton wrote:

1) Cookie session storage means that all the session data is stored in the cookie and encrypted (or at least signed) to prevent tampering. Alternatives are server based sessions, where usually a cookie is set with a session ID and all the data is stored on the server.

Just to confirm, when we call put_session/3 to put some data in "Plug's cookie session storage" (the default option), the data is stored in a response cookie that is sent back to the client, and we are not using server based sessions. Am I right?

[Andrew Timberlake]

Yes, with the default configuration you are not using server based sessions.

Andrew

--
You received this message because you are subscribed to the Google Groups "phoenix-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenix-talk...@googlegroups.com.
To post to this group, send email to phoeni...@googlegroups.com.
Visit this group at https://groups.google.com/group/phoenix-talk.

To view this discussion on the web visit https://groups.google.com/d/msgid/phoenix-talk/5a79c778-fc8b-438a-a15b-fb04494b9749%40googlegroups.com.

[Ed W]

On 29/06/2016 04:55, Peter Hamilton wrote:
>
> 1) Cookie session storage means that all the session data is stored in
> the cookie and encrypted (or at least signed) to prevent tampering.
> Alternatives are server based sessions, where usually a cookie is set
> with a session ID and all the data is stored on the server. Cookie
> based sessions are much easier to scale since you don't have to share
> data between multiple backend in a load balancer, drive all the data
> is included in each request via the cookie. Cookies are in practice
> bounded size wise and require a lot of redundant data transfer and
> parsing. As stated, prefer cookie sessions unless you really can't use
> them.
>

This is actually quite a dangerous thing to be doing unless the
application creator understands the implications?

For example you cannot (guarantee to) expire cookie based sessions, ie
the user can manually backup the cookie and re-present it later

Additionally it would be dangerous to store details such as "is user
logged in" or "does user have some permissions" in a cookie session
since it can potentially be (very) stale. The logical chain of thought
is to double check in the database, but then you might as well have just
put the session data in the database already

I'm a big fan of cookie based sessions, but they are incredibly
dangerous. If we don't already have documentation up on just how
dangerous and how developers need to work this limitation into their app
design then we are doing them a dis-service? This is such a big
limitation that it needs to be worked into the ground level (or move to
server based sessions)

Here is a thoughtful article on the problem, it also usefully debunks
most of the incorrect reasons for rejecting client side session data (ie
we get to the core of the problem)
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Ed W

[Peter Hamilton]

Invalidation is a very valid point.

Personally I limit data in the cookie to user ID and hit the database for other information. That's a pretty standard approach. It does not solve the invalidation problem.

Current documentation (quoting Plug) says:

We don’t recommend using this store in production as every session will be stored in ETS and never cleaned until you create a task responsible for cleaning up old entries.
Also, since the store is in-memory, it means sessions are not shared between servers. If you deploy to more than one machine, using this store is again not recommended.

It sounds like this is not complete and should be updated. Since you feel strongly enough about it to comment, could you open an issue on Plug and start a discussion there?

--
You received this message because you are subscribed to the Google Groups "phoenix-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenix-talk...@googlegroups.com.
To post to this group, send email to phoeni...@googlegroups.com.
Visit this group at https://groups.google.com/group/phoenix-talk.

To view this discussion on the web visit https://groups.google.com/d/msgid/phoenix-talk/c76f15ac-9be6-6e2b-f2b6-a5a18bfa7fc4%40wildgooses.com.