I'm trying to set up my sessions to run on the server but don't know how to go about it. I've searched for a while and I can't find a resource that helps me set up non-cookie based sessions. I've seen somewhere that SessionStore stores it on the server instead of the client but I can't find anything about it.(How it works or how it is set up) Can anyone help clear things up for me?
1 Answers
I know of three ways of keeping track of a user using your site: cookies and HTTPS conections using digital certificates and cookieless sessions.
Cookieless
The cookieless smells like being insecure even under HTTPS connections, because you need to pass an identifier (that would be a cookie in a "regular" session) somehow to the server, usually in your address call, like this:
http://www.somewebsite.com/page.aspx?sid=jrkwojeqrojq3op349023231234r23rf2
You should probably check this question, and this one on the security implications of it.
Also check this one explaining how to achieve this through javascript.
HTTPS and certificates
A HTTPS connection approach involves the user presenting his/her certificate to the server, at every request. Considering that the user will present the certificate at every request he makes to the server, sessions can be avoided entirely, because you will authenticate every request transparently.
I don't think it is possible to implement this approach without having the user generate and provide a certificate. This is not the usual "server-only certificate" HTTPS approach.
Cookies
Considering that you might not be willing to go the HTTPS path, the only way you can recognize that it is the same browser calling for another action is to have it give you a cookie back to tie to a session. There is possibly no way you can keep a session without a cookie and still have it protected from forgery or else.
The bottom line: the browser has to send you a way to tie that browser request to an ongoing session, so you can be sure (assuming you are encrypting your connections) that it is who it says it is.
Sessions are controlled by the server, and every cookie issued is recorded in a sessions-table so when the browser that holds that cookie calls again, it can the queried and identified by the server.
In one of the answers I linked earlier one of the answers describes a way to keep all the user information in the cookied, and so there is no need to query a session database on the server to identify the requesting browser. But that seems to be a little off of what you are asking.
Ruby On Rails
Rails approach to sessions is described in the Rails Security Guide.
Rails API's ActionDispatch::Session will list the Storage Mechanisms Rails provides for session information.
ActionDispatch::Session::CookieStore is a "server-less" session storage, so you have all the information the server needs to identify the session sent by the browser, in a cookie. That's most likely what you meant in your question.
But that is not more or less secure than storing session information in the server-side, like using ActionDispatch::Session::CacheStore or some other way of keeping session information. But is is a lot faster.
Bottom-line: when using cookie-based sessions, what differs in the storage methods is access and response time, not security.
If you want to go with security, I would suggest going sessionless with HTTPS certificates, but that is unfeasible for the majority of the general public web applications.

- 1
- 1

- 513
- 3
- 10