I'd like for people to "vote" on things without having to be logged in. The way I'm thinking of doing this is via a cookie.
What would be a recommended way for tracking these cookies per a post?
E.g, a user views a post, and then "votes it." Now that post vote is stored in a cookie and when that user visits that page it'll say they voted for it.
Should I create a cookie per post, or a cookie that is a hash of all the posts they voted on?
Tips/examples of code would be appreciated. Thank you.
You can access cookies via cookies[:cookie_name]. More details here: http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html
I think you are going in the right direction, cookies are made for this type needs only for storing insensitive information like the search history. Just remember not to give the cookie any expire time and it will remain stored in the users browser, and most of the normal users won't be clearing cookies so it will not be a problem for you.
you can use it like this cookies[:voted] = true put this when you register a vote, and every time before voting check this
if cookies[:voted]
return # or show that you have already voted
if you also want to save the vote that they caste last time you can just save that in the cookie for retrieving the next time.
Related
Currently, I have a Rails application whose edit form is on a separate edit page. Is there a way to make sure no two users are accessing the edit page at the same time? Or a user can only access the edit page if no other user is currently on the page?
Or to ask a simpler question, is there a way to get a list of users currently on the page?
I am on Rails 4.
HTTP is a stateless protocol. It was designed to allow idempotent transactions. The server does not store transaction state information about each chain of requests. The session allows you to mitigate this design pattern and allow the server to track where your users have been. In order for you to know if a user is on a page, you will need to store in your database where each user is. Remember, that when a user decides to navigate away from a page, your servers will not know it, only when a request is made to a different page.
I assume you don't need to track anonymous session information, so you probably need to override your controller action that ensures users are logged in to save where the user is at. Before rendering the page, ensure the count of user's current location equal to the rendered page is 0.
You can have AJAX fire on the page, updating the location of your user on these pages so you can ensure that there has been no user in a reasonable timeout. Without the AJAX you would need to consider what the reasonable amount of time a user would be editing information, and consider that a non-reasonable amount of time is likely the actual amount.
There's no 'RAILS' feature that can be turned on to check where a user is located, this would be a roll your own situation.
I think the best way is to use a Redis Store (or anything in memory), or make a temporary sessions table for that.
Then you can authorize the show action to check whatever you want.
Relatively new rails programmer here, so bear with me.
I have an app where registered users can create polls but anyone can answer the polls.
I am using Devise for my authentication. I want non-authenticated users to be able to answer the polls but I want to prevent double-voting.
I assume this should be done with persistent (not session) cookies, but I'm not sure. So when the user enters the site, I create a user in devise and I store some random value in both the User model and in the cookie, and I check that the user has not answered the question previously when he/she attempts to load my "answer" page?
Can someone give me some advice on whether this is the right approach and/or point me towards a resource to help me get started?
I have found relatively little information out there on how to manage persistent cookies in Rails.
You can't reliably prevent people from voting multiple times without logging in. It's not possible. I guess people could also create multiple user accounts to vote so there is no fool proof way.
Cookies are often cleared automatically by certain popular cleaners and unless you are only going to allow people to vote on a product they have purchased I think you are kind fighting a lost battle.
Stack Overflow limits voting capability by making sure a certain level has been achieved before being allowed to vote but I guess that's not really applicable to your scenario.
This is not so much about sessions and cookies and more about setting up your database to record a vote including the voter id.
In the view that allows users to vote I would suggest that you switch between a voted icon and a vote now link depending on whether or not the currently logged in user has voted.
To determine if the user has voted then include the user id of the currently logged in user in a question_vote xref table.
For the belt and braces approach to prevent abuse of the html in the browser add the check to the validations of the question_vote record.
I would do this by adding a can_vote? method to the user model that accepts a question id as a parameter then you can use the question_id plus the user id to find a matching record in the question_vote table if a reordx is found return false otherwise return true
i have a question-answer survey..
Only one user can answer on survey! User cant click on previous button (in browser) and once again pass the survey. How i can possible do this? I need sessions and unique token? Please help me, i;m stuck with this...
If you have user-login, then you only need to validate whether they have already voted or not. This is really required to be 100% sure of no dup votes.
If not, you can't 100% guarantee dup votes, but you could make it difficult:
store in the session[:voted] = true
on receiving a vote submission don't accept if session[:voted] == true
Obviously the user can clear cookies which will clear your session.
You could enhance this by logging ip's but then consider proxy-servers (all users from behind the proxy will appear as coming from the same IP -- the proxy).
I you must enforce this then I imagine you'd require users to login and then you can store which surveys / survey sections they have already answered in your database.
Otherwise it's generally enough to prevent people from filling in surveys multiple times by storing their ip address in your system and also setting cookies on their browser based on which sections they have already completed. They can get around this by clearing their cookies but at least if you store their ip address they'd need to change ip to redo the survey.
It's hard to say without knowing the context of the survey. Is it on an existing app where users already have accounts? Is it standalone etc.
Thnanks guys for respons.
I thought about this (user-login), but i want to without it.. so i give link address, user get it, click on this address.. like www.blabalbla.com/test/survey/32643928569832569 (unique token).. and user can pass survey.. then when he finished he cant pass this survey again on this link.
so I have designed this voting thing which does not let somebody vote for the same article twice in 24 hours. However, suppose a person votes and after seeing the person was able to cast vote or that he is falling in that 24 hour window, I disable the vote-casting button (and this is all Ajax btw).
But what to do when a person closes his/her browser and comes back up or even refreshes the page? Obviously, he would not be able to cast vote, because of my algorithm, but the person would still end up succeeding in making call to the server. So if he really wanted, he would keep refreshing the page and clicking on the vote and put unnecessary load on the server. How to avoid that by doing some sort of client-side thing or something?
I am using ASP.NET MVC, so session variables are out of question.
Am I being over-concerned by this?
If voting happens only from logged in (known) members then you shouldn't have any problem.
If, on the other hand, everyone can vote then you need to store all user vote events:
timestamp
poll
poll_vote
ip
user agent
user uniqueness cookie
So you'll need a random hash sent out as cookie. This will ensure that you don't accept another vote for the same poll from the same person.
If the user deletes his cookies you fallback to plan B, where you don't allow more than (say) 10 votes from the same IP and user agent combination for 24 hours.
The system is not perfect since users can change IPs and (more easily) user agents. You'd need advanced pattern detection algorithms to detect suspicious votes. The good thing about storing all user vote events is that you can process these later on using a scheduler, or outsource the votes to someone else who can process them for you.
Good luck
Refreshing is not a problem
If you're doing all this voting using Ajax, refreshing a page won't do anything except load the page using GET.
If you're not using Ajax you should make sure you call RedirectToAction/RedirectToRoute action result, that would as well help you avoid refresh problems.
How do you recognise users
If you use some sort of user authentication this re-voting is not a problem. But if your users are plain anonymous, you should store IP address with your votes. This is how things are usually done. This makes it possible to avoid session variables as well. But you have to be aware of this technique because it's not 100% perfect.
Cookies?
You could of course also use absolute expiration cookies. They'd expire in an day. Advanced users would of course be able to avoid your voting restrictions, but they would be able to avoid other ways as well. Sessions BTW are also based on cookies anyway.
Combination
But when you'd like to make you system as great as possible, you'll probably use a combination of the above.
The best way would be to track who voted for what and when on the server (probably storing it in a database). In order to do this you must use an authentication system on your site (probably forms authentication) to identify users. So every time someone tries to vote you check first in your data storage if he already voted and when and decide whether to validate the vote or not. This is the most reliable way.
If your site is anonymous (no authentication required to vote) then you could store a persistent cookie on the client computer that will last for 24 hours and indicate that a vote has already been cast from this computer. Remember though that cookies might be disabled, removed and are not a reliable way to identify a given user.
I am using ASP.NET MVC, so session
variables are out of question.
Any reason for that? Sessions are perfectly fine in ASP.NET MVC applications. It is in your case that they won't work because if the user closes the browser he will lose the session.
Obviously, he would not be able to
cast vote, because of my algorithm,
but the person would still end up
succeeding in making call to the
server. So if he really wanted, he
would keep refreshing the page and
clicking on the vote and put
unnecessary load on the server
Automated bots could also put unnecessary load to your server which is much more important than a single user clicking on F5.
If you just want to ensure the user can only vote once on an article then you just need to store a Set (i.e. HashSet) of all article id's that they've already voted on, then just check before allowing the vote.
If you still wanted a 24hr limit then you need to store a Dictionary<articleId,DateTime> then you can check if he has already voted for that article and if he has when it was.
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.