How big is the performance penalty switching from the cookieStore to the ActiveRecord SessionStore?
By default Ruby on Rails uses the CookieStore. But it has the disadvantage that the client needs to have its cookies enabled.
Switching to the Active SessionStore seems to solve that problem. I'm considering switching.
I read that performance is worse using the ActiveRecord SessionStore. But what is worse? Will a user notice this, or is it a matter of milliseconds? Anybody has seen benchmark results comparing the 2 options?
Any other reasons (not) to switch to the ActiveRecord SessionStore?
What is worse is that it needs to query a database, which then needs to calculate the answer, rather than going straight to the cookie on the client side.
However is it really that bad? You are correct in that the performance difference is very minuscule in most cases.
Pros:
Affinity-
If your web application ever expands to more than one server, moving your sessions to a database can allow you to run your servers without server affinity.
Security
- Since you only store the session ID on the client side, this reduces the chances of the user manipulating any data via the client side.
Cons
Performance - Instead of querying the database, you can just read the session/cookie data from the client side.
But the AR session store also depends on cookies - it saves the session id there.
As far as I know there is no way to make Rails sessions work with cookies disabled.
Related
I am currently creating an iOS application with Swift. For the database I use Firebase Realtime Database where I store among other things information about the user and requests that the user sends me.
It is very important for my application that the data in the database is not corrupted.
For this I have disabled data persistence so that I don't have to store the requests locally on the device. But I was wondering if it was possible for the user to directly modify the values of the variables during the execution of my application and still send erroneous requests.
For example the user has a number of coins, can he access the memory of the application, modify the number of coins, return to the application and send an erroneous request without having to modify it himself.
If this is the case then is it really more secure to disable data persistence or is this a misconception?
Also, does disabling access to jailbroken devices solve my problems? Because I've heard that a normal user can still modify the request backups before they are sent.
To summarize I would like to understand if what I think is correct? Is it really useful to prevent requests to save locally or then anyway a malicious user will be able to modify the values of variables directly during the execution and this without jailbreak?
I would also like to find a solution so that the data in my database is reliable.
Thank you for your attention :)
PS : I also set the security rules of the db so that only a logged in user can write and read only in his area.
You should treat the server-side data as the only source of truth, and consider all data coming from the client to be suspect.
To protect your server-side data, you should implement Firebase's server-side security rules. With these you can validate data structures and ensure all read/writes are authorized.
Disabling client-side persistence, or write queues as in your previous question, is not all that useful and not necessary once you follow the two rules above.
As an added layer of security you can enable Firebase's new App Check, which works with a so-called attestation provider on your device (DeviceCheck on iOS) to detect tampering, and allows you to then only allow requests from uncorrupted devices.
By combining App Check and Security Rules you get both broad protection from abuse, and fine-grained control over the data structure and who can access what data.
In my Rails app, once per user session, I need to have my server send a request to one of our other services to get some data about the user. I only want to make this request once per session because pinging another service every time the user makes a request will significantly slow down our response time. However, I can't store this information in a cookie client-side. This information has some security implications - if the user has the ability to lie to our server about what this piece of information is, they can gain access to data they're not authorized to see.
So what is the best way to cache or store a piece of data associated with a session on the Rails server?
I'm considering using Rails low-level caching, and I think it might even be correct:
Rails.cache.fetch(session.id, expires_in: 12.hours) do
OtherServiceAPI.get_sensitive_data(user.id)
end
I know that Rails often has one canonical way of doing things, though, so I want to be sure there's not a built-in, officially preferred way to associate a piece of data with a session. This question makes it look like there are potential pitfalls using the approach I'm considering as well, although it looks like those concerns may have been made obsolete in newer versions of Rails.
Is there a canonical pattern for what I'm trying to do? Or is the approach I'm considering idiomatic enough?
When building an ASP.NET MVC application with a goal of high availability, is it a good practice to keep the session state on the SQL Server, if there is no state server available?
The point here realy is that you have 2-3 webservers like you mentioned in the comment to Craigs answer.
One way is to use SQL-server sessionstate which has its own problems http://idunno.org/articles/277.aspx.
If you have this one SQL-Server I would be carefull, because the DB for sessionstate will put heavy load on it. Each request will write to the db.
We use 2 webservers and a Loadbalancer that has sticky sessions. If your first request ends up in server 1 then all your requests are handled by server 1. (Its a bit more sophisticated but you get the idea.)
This might not allways be the best solution, but at least on our site (its a shop where user typically stay 20-30minutes) it works well. We use only little SessionState and have most of the userspecific stuff stored by the ProfileSystem. But I guess the ProfileSystem will also fail if requests go to different servers.
I'd suggest AppFabric Caching (f.k.a. Velocity) instead.
I want to integrate a shopping cart in my site. The cart should be such that it resets once the user signs out of the application. This can be either achieved via sessions or using the database tables.
What should be prefered out of the above two? Are there any security loop holes if this is handled via sessions?
In the security department, none of the two are prefered over the other. You should understand that both concepts are basically "sessions", but one is handled in the appdomain, the other is handled in the DB-domain.
Appdomain sessions:
Faster (No round-tripping to database)
Not scalable
Prone to concurrency problems on server farms
Sessions will be lost on server restart
Database sessions:
Slower (Roundtrips to the DB for each request)
Easier to scale on serverfarms
Sessions will be kept open on server restarts
You should consider how many users will be using your site. If you are looking at a lot, you are probably going to need multiple servers, in which case the database sessions will be your best bet, if you will stay with a single webserver / database server, then appdomain sessions will do fine.
I don't see why HttpSessions increase your security exposure - if your session is hijacked then presumably so is your DB access.
If you really intend that your user's cart should be transient then clearly your HttpSession is sufficient. Scaling app servers usually have session replication capabilities to deal with individual server failures.
I'm sceptical in the long term that such a volatile cart will always be what you want, I find it very convenient to browse around Amazon and assemble my cart, then just leave it for while. As it's probably not a great deal more work to persist your cart in a DB, I'd probably go for that.
I would use Sessions - no point of clogging up your DB on data that will be destroyed on log out.
Plus, Sessions are quite safe to use.
Is there a way to persist data between page loads in RoR? I guess I'm looking for something like memcached, but without the overhead of TCP/IP. For example, PHP has APC.
The ideal solution would be something in memory.
Why don't you just store it in the session? The session can have multiple backends like memcache or even a database. I think it is possible to deploy memcache locally so It wouldn't matter that much.
Another posibility is to use a file backend and store it on a RAM drive. But maybe there are some memory libs for ruby which allow you to store these results directly into ram, but I got no experience with it.
cookie based session stores are wicked fast, require no serverside storage or fetching, are secure, and the Rails default. As long as the data is less than 4K no reason not to just use that.
How much data? If this is small, you could store it in the session data (i.e. session[:my_data] = "foo").
I wouldn't call the TCP/IP component "overhead" -- unless you are running the memcached server in another state or something. Memchached can be run locally just fine and rails works great with this. Perhaps memcached even has the ability to use a socket file instead of a IP and port, but I have not looked into this
You can also serialize ActiveRecord models. See the serialize method.