Difference between Cookies and Sessions

[Praveen BK]

Hello,

Can anybody please define cookies and sessions and their
differences in detail with reference to rails.


Thank you,
Praveen

--
Posted via http://www.ruby-forum.com/.

[Andy Jeffries]

Cookies are stored key/value pairs (with other attributes such as expiry, domain, path and ssl requirements) in the client's browser.  The specification for them is in the HTTP specification and these can (generally) be read by backend languages such as Rails or frontend technologies such as Javascript.

Sessions are an unrestricted storage area for applications, generally used by the backend language only (due to encryption and hash protection with server side secrets), although they may be stored in their entirety in a client-side cookie for convenience to avoid "sticky sessions" where requests have to come back to the same backend server.

Hope this helps.

Cheers,

Andy

Andy Jeffries Ruby on Rails, RubyMotion, jQuery Developer & Taekwondo 6th Dan Instructor

andyjeffries.co.uk +44 7939 164853 @andyjeffries fb.com/andyjeffries

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/6c917df7bf555a6e49a8fbfb68cd6144%40ruby-forum.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Walker]

Praveen BK wrote in post #1151760:

> Hello,
>
> Can anybody please define cookies and sessions and their
> differences in detail with reference to rails.

What may be confusing you, that I've not seen mentioned yet, is that
session identifiers are stored in cookies. Let me explain by looking at
the process...

Actors:
- User Agent (Web Browser)
- Local storage (Cookies, Local Storage, etc.)
- User (Person using User Agent)
- Application (Server side Rails, PHP, ect.)

1. User enters URL into address bar of User Agent (e.g.
http://example.com/).
2. User agent looks up cookies in Local Storage matching domain (e.g.
example.com).
3. User agent sends request, with attached cookies, to Application.
4. Application parses incoming request, extracting any cookies found in
request.
5. Application searches for session cookie. Goto to #7 if found.
6. Application creates new session cookie if necessary
7. Application renders response.
8. Application attaches all cookies to response.
9. Application send response to User Agent.
10. User Agent extracts cookies from response.
11. User Agent stores cookies from response in Local Storage.

Noticed #6 says "if necessary". It's possible to have session-less
requests (i.e session only on demand)

As you can see the "session cookie" is a cookie like any other. It is
nothing more than an opaque identifier used to track a User between
requests. Requests in HTTP are stateless, there is no way to know that
two requests are really part of the same Application session. The
concept of session is at the application layer and not at the protocol
layer (HTTP), which has no notion of application session. To work around
the stateless nature of HTTP we use cookies in order to emulate state.

Session cookies are cookies, but not all cookies are session cookies.
Sometimes you just want to store arbitrary data in the User Agent's
Local Storage, and have the User Agent send it back to you on subsequent
requests.

Session cookies are not to be confused with Rails's cookie based session
storage. This is also implemented using a cookie, and is separate from
the session identifier cookie. Session storage cookies, of course, have
the same limitations as any other cookie (because they ARE just a
cookie). The limitation of the most concern is the 4K size limit. You
cannot store more that 4K (total) for each Rails session, including the
overhead info Rails puts in the session storage cookie.

Normally this is not a problem since you want to minimize the amount
information you store in a session. A common item for session storage is
the User, so that you can match a specific session to a specific user of
your application. It is important to understand that there is no need to
store the entire User model in the session. All you need to store is the
"id" of the User model so that you can lookup the actual User model on
each request. (Example: session['user_id"] = some_user.id NOT
session["user"] = some_user)

Hope this helps clear thing up for you.