I am Biulding an mvc asp.net website i want to add polls, i want to check if the user vote before what can i use:
1. IP : there is the problem of private and public IP
2.Cookie can be deleted
help please.
The only reliable way to achieve this is to require your users to authenticate to your site before voting. This way you can store the information that a user has already voted in your database. This way when a user logs in and attempts to vote you will know whether he has already voted or not.
If you allow anonymous users to vote on your site there just is no reliable way to do this.
Related
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'm working on my first simple Rails app in which users submit sport "tweets" (e.g. "tennis, squash") and the server matches them up with partners. The server will return you a list of SportMatches based on similar tweets and you have different options (e.g. email, SMS) to reply back to someone's tweet and accept him/her as partner. Initially, the modeling was straight forward since: User has_many SportTweets and SportTweet belongs to User. Notifications were simply part of the User, or they could have been modeled as a 1-to-1 relationship to User.
My business requirements changed a little, as now I have anonymous users who can also post SportTweets. Because they don't have an account/profile, they must also submit notifications (e.g. email, SMS) with the tweet. I don't know how to model this the Rails way. SportTweets are now either anonymous, or authenticated-user-posted (AUP). So, now, my SportTweets table will have the following columns:
type: either "anonymous" or "AUP"
user_id: only for AUP
notifications_id: only for anonymous
sports: for all
post_date: for all
post_location: for all
etc.
There would be a Notifications table. A notification record would belong either to a User, or to a SportsTweet. I guess I would model this with polymorphic associations.
That just doesn't look like the Rails way. Did anyone come across a similar problem? How did you solve it?
Did a bit of searching and the answer is STI. See The Rails 3 Way - Chapter 9.
Use Devise if you can. I think this link might help you.
In some applications, it's useful to have a guest User object to pass around even before the (human) user has registered or logged in. Normally, you want this guest user to persist as long as the browser session persists.
Our approach is to create a guest user object in the database and store its id in session[:guest_user_id]. When (and if) the user registers or logs in, we delete the guest user and clear the session variable. A helper function, current_or_guest_user, returns guest_user if the user is not logged in and current_user if the user is logged in.
Followed by the code which you might find helpful in that page
I'm using devise/cancan for my app and everything is pretty sound -- provided a user creates an account and signs in.
What I'd like to do is allow a user to get started without creating an account. And then sign up if they want to actually save their work.
Has anybody come across this before? Should I be figuring out how to create dummy accounts with devise? Or allowing unauthorized users access to creating models in my app via CanCan?
I could go into detail about how I've been thinking about approaching this, but it feels like a pretty obvious use case that somebody has come up with a nice solution for.
Thanks in advance,
Mike
If you go with creating dummy accounts, you would have to track the user somehow via a cookie and cache the values in that cookie in your db. Cancan does allow for guest accounts via the ability model. For example:
user ||= User.new # Guest user, for users who are not registered or don't have an account yet
Which is enough you to you started with applying permissions for non registered users. Note though, tracking by cookie alone is not very reliable and can lead to some type of security hazard (i.e. by means of cookie hijacking). User, one day, can also decide to clear out his cookies.
If need be, I would suggest letting the user do minimal interaction with a guest account and motivating the user to sign up / register with Devise as much as possible.
Hope that helps!
I actually am considering the same problem, I have a scheduling app that makes a calendar. To get over the problem I'm thinking that you use
user ||= User.new
Like was suggested above and using cookies to get the data to the database once the user creates an account.
This would mean that you would not have to worry about clearing out cookies because they would create an account if they want to save data.
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.
Is there any way to limit a user's login access to only, say, 5 IP addresses daily? Such that if a user account tried to login in the same day from a 6th different IP address, they would be denied. I would like this restriction to reset at the end of the day, however.
If Authlogic doesn't provide a way to track this out of the box, what ideas do you have about how I should implement this? As you can probably tell, I'm already using Authlogic for authentication.
My main goal is to limit my user's ability to share their login with a non-registered user; I know that most people's IP address will change periodically throughout the day because hardly anyone has a personal static IP, but I think 5 is a fair number of allowances, even taking into account that a user may visit my site on their iPhone, or at Starbucks, etc.
Thoughts?
UPDATE: After reading through many of the comments on the link provided by #tadman, I'm thinking that it might be more useful to limit the number of new sessions created on a machine that had none previously instead of by IP address. If I understand how Authlogic works, sessions are a combination of server-side records and a cookie in the user's browser, correct? If I "log out" of my site, the cookie is still there in my browser, is it not? Just with an expired value or something like that. Can I test against that? Such that if a computer that doesn't have that cookie at all I would consider to be a completely NEW login, and I would limit the number of new logins to 5 a day? Would that be feasible approach?
See this user's comments about rate limiting by IP for an angle on what I mean: http://simonwillison.net/2009/Jan/7/ratelimitcache/#c43031
Although you can track this in a database, a more lightweight solution is to track this using Memcached. This allows you to do other things, like limiting login rates and restricting the number of unique IPs a person may visit from over the course of a given time.
The nice thing about Memcached is it will automatically expire records after a specified period of time. With the database-driven approach you will have to do this yourself.
Example: http://simonwillison.net/2009/Jan/7/ratelimitcache/
I'd probably create a table called sessions, which contains ip_address, logged_in_at, user_id. You'd do something like this when a user logs in:
session = current_user.sessions.build(:ip_address => ip_address)
if session.valid?
session.save!
redirect_to root_url
else
redirect_to you_cant_login_url
end
In your session.rb, you'd have
class Session < AR:B
belongs_to :user
validate :hasnt_logged_in_a_bunch
protected
def hasnt_logged_in_a_bunch
if self.user.sessions.count(:conditions => ['logged_in_at > ?', Time.now.start_of_day]) > 5
self.errors.add_to_base("You've logged in too many times")
end
end
Sorry if this is a bit ugly and isn't valid code, but it should hopefully point you in the right direction.