I am new to Redis and started playing with it.
I have a rails app where unauthenticated users can put newspaper articles as favorites, so they could read them later. What I have been doing until now is storing the favorites in cookies.
But I would like to achieve the same with Redis.
There is the command lset. What I don't understand is if this list will be unique to each visitor or common to everyone.
Redis is a key-value database, if you use same key for every user - then list will be common for everyone. Uniqueness can be achieved by adding some user id into the key.
If you want to add an article id to users' list - RPUSH is more suitable, because you do not know which list index the article will be at.
Other problem is data expiration, because anonymous users' data is useless once the user clears their cookies/change browser etc. In this respect cookie storage is more preferred. If you worry about cookies size - you may look into using localStorage on clientside. Also you can use rails' redis session storage - this way cookies only contain session id and all data goes to redis (where rails will care for it's structure, users are unlikely to face race conditions in your task)
Related
I've seen some information on SO and Google regarding storing user data for sessions, but most have been for PHP and not Rails.
Additionally, I've watched Dangers of Model in Session on RailsCasts.
Let's say I have a user that logs in, and I want to access some basic preferences from the user like: zip code, height, weight, and perhaps, 10 other things that I would like to access later.
Should I?
Store those 10 things in a hashed session variable?
e.g., session[:user_prefs] = User.find(:first)
Just store the user's ID as a sesion variable, and then run queries later to access the zip code, height, weight, etc?
e.g., session[:user_id] = User.find(:first).id
Or, is there something entirely different that I should be doing?
I'm not sure what the standard coding practice or best practice would be for this scenario.
Any help would be great.
Option 2 is the way to go.
Option 1 is "No" because your session data will be out of sync with the database as soon as the user information gets updated. Say for example you store those ten fields in the session upon user login, and later in the application the user updates one of those ten fields, now the session data is out of sync with the database. You could define a function that updates the session data when one of the attributes changes but I think this adds unnecessary extra complexity to the application.
Option 3, I cannot think of anything that replaces the session for this requirement. There are other ways you could implement the session logic but they would just be your version of already provided(by Rails) implementation of session.
Currently, the site is storing "previously viewed items" via cookies.
I need to take that a step further and not only store those items in the database, but save the user's most recent search, so that they can retrieve the search later by returning to the site (the cookie can handle this), but also through say a four-letter code and later a QR code.
When you get into writing these non-authenticated users' data to the database, what is the identifier to use as the key to differentiate them? And would it be ideal to create the actual model record upon visiting the home page, or perhaps after the initial search?
You could save the IP address, other than that, there is really no way to save something specific to a user.
Use the rails request object. You can access the IP with request.remote_ip.
This is the only thing I can think of that is request specific without auth.
My Scenario:
Sessions are being stored in the database using ActiveRecord::SessionStore
User is on site at 'http://domain.com '
they go to secure checkout at 'https://domain.secure.com' (our app has lots of domains, but want to send everyone through secure checkout on the same domain to save SSL headaches).
We append session_id and a hash to authenticate and identify the user at 'https://domain.secure.com'
Load that users session data by doing ActiveRecord::SessionStore::Session.find_by_session_id(session_id)
The above all works fine. BUT how can I actually set the same session_id to the user once they are on 'https://domain.secure.com'? I can loop through the data and assign it to the user's session, but Rails automatically gives the user a new session_id on 'https://domain.secure.com'. I want the users session to be stored in the same database row regardless of whether they are on 'http://domain.com' or 'https://domain.secure.com'
Why do I want to do this? For ease of expiring sessions. I can just remove that row from the sessions table.
Otherwise I'm thinking I'll have to add a user_id column to the sessions table and then when i want to expire the session, I delete all rows for that user. But this sounds more complicated to me. I'd rather just have one row in the sessions table.
Any suggestions?
A couple ways to approach this.
One, you could look at a higher level of abstraction for authentication that lets you manage cross server. For example, Devise http://github.com/plataformatec/devise
Second, you can override the whole session controller and write your own session manager. A bit more work, but not that complicated if you ultimately need a bunch of custom functionality. I remember correctly, start with this in your environment:
CGI::Session::ActiveRecordStore.session_class = MySessionClass
and go from there..
I'm trying to run my site off the lazy idea of not having user registrations.
Anyway, I want a user to be able to "favorite" items on the site when they click "favorite" off of an "item"
I'm assuming I need to use cookies for this but I don't really know the next step. Could anyone point me in the right direction?
Thanks!
Not rails specific, but I dislike the idea of storing too much stuff in a cookie. Instead I store it on a database on my web site, and just put a primary key value in the cookie. That way you can store as much or as little as you like without transmitting too much over the net. The disadvantage of the "no registrations" approach is that they lose all their stored data if they change to a new computer, or even a new browser on the same computer.
What I do in my app is to store a cookie with a "session id". Then I have several tables, one stores one-off data like the last date that session id was seen, and others store multiple items per session id. I have a "session_states(session_id, state)" table, for instance, that stores one record for each state a person chooses from a list of US states.
One reason for storing the last date is that I purge any session ids from the database that haven't been seen in two years (because I give an expiration of +2 years when I create the cookie).
Maybe you could learn more about cookies on Rails. This link has a lot of information about this topic. I think that you will appreciate it!
But take some care to not store too much information using cookies.
What want to be accomplished is:
I want to "synchronize web browsers". my site has a "wait URL" where when browser gets there it will be kept waiting till another browser also go there and then both will be presented with a quiz-like game.
Right now the wait url will call each second to Rails to check if other player came to the game. How can in the Rails framework detect a different client connecting to the same URL?
As the controller is recreated per request looks like is not the place, not the view for sure and storing this in the model looks really clumsy.
Also, after the pairing I need to check and compare every answer of the paired users so somehow that information must be retained
What you're trying to do is share information between users. So the database or memcached are the most sensible.
Simplest: I'd create an ActiveRecord object, perhaps called Quiz, instances of which people join by virtue of going to a URL, e.g using default routes:
http://yoursite.com/quizes/join/3434
You'd need an ajax poller poller to notify the others; use periodically_call_remote for this -- you could use render :nothing => true by default and render something else if there was an error to keep it efficient. You can also use the frequency method as a basis to determine whether people leave the quiz as well (e.g. if frequency is 1s, then assume someone has left if they didn't ping after 5-10s).
Assuming these users are not registered with the site so don't have some kind of user id you could store I would suggest using the session. It is a per user data store. By default the session is stored in an encrypted cookie on the users machine. However you can use ActiveRecord as the session store and could maybe query that table directly?
Store the URL in the session and do a search for it at a later time. You can normally only access the current users session using the Rails 'session' hash but maybe (untested) if you created a model called Session (or maybe something more specific like 'WaitingGamers') which used the sessions table you could lookup the information you need.
I would guess when using ActiveRecord as the session store the session data is stored as a serialised hash. Use Marshall to turn it back in to a regular hash and find the data you stored in there.
I'm not a rails expert, but since all the state resides in your database that would be the place to keep this information.
You could keep a "waiting users" table, and in the "wait URL" view check if the user is already in the table. If not, add him to the table. Then, check if there is another user waiting (maybe there's more than one?) and if so, match them up and delete them from the table.
Another improvement would be to keep a timestamp for each user in the "waiting users" table, which gets updated in the view - this would serve as a keep-alive that will enable you to detect users that left the "wait URL" page or closed the browser.