I currently have a website built in PHP, I'm hoping to build a referral system tonight.
My theory is that if I dynamically generate a url and place it on my users' homepage such as
"Referral url = www.mysite.co.uk/referral.php?user=myuser"
Then I could have a script in the page referral.php which gets the username and runs an sql query updating their corresponding row in my table.
The only thing is anybody could then add there own name and sign up multiple accounts.
What is the best way to go about building something like this?
Thanks
Suppose to get the referral url my users had to click a button which generates the referral url as a rand ie mysite.com/refer.php?user=234234, at the same time storing it in a the db.
Once somebody visits the page refer.php, the referrer then gets his credits or benefit added to his row in the db, at the same time setting his referral code to 0, making the code only available once.
Each time he hits the button on his page, his referal code would change.
Would this be valid do you think?
You generally have the right idea, but protecting against fraud in a referral system is difficult. You can check for unique IP addresses in $_SERVER and add that to the database for each request, throwing away duplicates or limiting referrals from IP addresses that don't come from the user who signed up. Like HTTP_REFERRER, this can be spoofed as well with ease (using TOR for example).
It's a tough problem that isn't something you can truly "solve." Like most fraud cases, you can only do your best to mitigate the effect.
EDIT TO ADD: You can also require referrals to "mature" by forcing the referred user to be active on the site for a defined period of time (say, 30 days) to increase the effort of spammers/cheaters. But again, this doesn't "solve" the problem - all you can do is make it tougher for them to game the system. And occasionally, by doing this stuff, you can ruin user experience. So how do you balance it? Tough question. :)
EDIT TO ADDRESS YOUR EDIT: Contemplate the following scenarios if we implement your plan:
1) I click the button and get my code. Then I paste it to... who exactly? One person? That's not particularly good for sharing on Facebook, MySpace (does this exist?), or my personal blog. I have to generate a referral code for EVERY person I send to the site? That not only scales terribly, but is a horrible user experience as well.
2) Let's say I figure out what you're doing. I develop a bot that clicks that button 4 trillion times. What now?
You could use the 'HTTP_REFERER' value to check what page the request came from, and only allow votes for that user from their page. This can be spoofed, but most people won't know how.
You can count the referral points for some additional action on your site, for example registration or payment or anything that is behind captcha check.
But do not build any obstacles for your regular legit users!
you could embed this information in the POSTDATA - it's a tad more secure.
Or you can add a restriction that any user may be upvoted ONLY by any other EXISTING user only once. And to make it more "secure", generate userIds with a random seed.
Related
Let me start by stating this : I absolutely do not wish to bypass the captcha.
I am using a particular website (lets call it "Swidili"), that shows a list of websites based on a theme and ordered by votes they got from the users. These votes are limited by IP adress and time (one per hour).
I wish to gift something to the users of my own website (lets call it "Badada") that vote for my website on Swidili. My issue is that I have no way of knowing if a user really voted. There is a cookie response that you get when you vote (vote=y) that lasts an hour (or until you can vote again).
Obviously, I can't read the users cookies from another domain. There is also no API made available by the owner of Swidili. I tried contacting him, but he does not seem to wish to answer me. Since it has now been a couple of months, I'm trying to find another way.
The solution that I thought of would be to show the captcha on my website, and then send with curl the result of that captcha. That way, the user is able to vote, and I can check if the vote is real by getting the cookies back from curl. Unfortunately, that does not seem to be possible, since ReCaptcha2 is limited to specified domains.
I have asked other webmasters, and they seem to have found a solution, but refuse to share it with me. I was wondering if there could be another way to get this cookie. Am I doomed ?
I'm currently working on my Referral System, but I have a problem with protecting it of frauds.
Okay, here's how it works for now:
user registers and activate it's account
user now have access to the control panel and there is it's uniqe link in following format: domain.tld/ref/12345
when someone other click to user's link, he or she must to click a specific button to confirm that is not some kind of fraud (like "click here, you'll get $100" or something)
system writes visitor's IP in a database and some data to cookies to prevent re-pressing the button. User now have +1 point.
But, the problem is that visitor can change it's IP, clear cookies and hit button again. It takes a few seconds, and that's not OK, that's cheating.
How to prevent it? Is there some trick to get some unique computer ID or something can't be changed that easy?
Really the only options are to tie the process to something which is not so easily manipulated by the user - super cookies, browser fingerprints, OpenID, Email addresses and telephome numbers (the latter 2 using some sort of validaton step before a vote is counted)
The only way you can be certain a referred party does not reuse a referral code is for the original user to send different one-time-use-only referral URLs to each person. Once the code has been used, it is flagged as such in (or removed entirely from) your database so that it can not be used again.
How you prevent the original user from sending multiple links out to the same person is another matter - and not an easy one to resolve.
Who do you perceive to be the threat?
Although it's certainly not 100% accurate, you can still fingerprint visitors using for example a combination of their ip, browser user agent, and with some javascript you can even go for screen size or installed fonts. Using these pieces of information you can set up a system where you save the fingerprints in datatable and in the same record you store the session id (from the cookie). Now when a new visitor arrives you can test their fingerprint against the db of recent fingerprints with different visitor ids. If you find a large number of matching fingerprints (you define the threshold) with different sessions then you can alert for the possibility of fraud.
Cheers
How about storing the link with with the user when they navigate to the link. then in the database you will have the link and if the users has already been to the link then deny them. Seems like it could work then you wouldn't have to worry about the cookies etc...
I would like to track all views to a page using php and mysql. I will be tracking the number of times a person viewed the page and the ip address along with the current date. However is there a way to make sure your tracking actual users rather than bots/spiders?
Two options that I see:
Create a "hidden" link on your home page to a honey pot. Any one who hits the honey pot page should be considered a bot and not included in your stats
2: Not a fool proof way, but you could compare the browser's User Agent string to a white list of known web browsers. This string can be spoofed so its not the most reliable.
Personally, I'd go with the first option.
For the honey pot:
on your home page I'd add something like this:
ReallyNotATrap
and on the honey pot page itself something like this:
$BotIp=$_SERVER['REMOTE_ADDR'];
//DB connection
Insert into BlackList($BotIp,$Date,$otherDataYouCareAboutLogging);
//close DB Connection
Then for your stats code simply compare every user's Ip to the BlackList table. If the user isn't on it, record the stats.
EDIT
As pointed out below, googlebot can get tricked by this. If this is something that matters to you (if your just filtering for your own stats and not filtering content it shouldn't matter), include your honeypot page in your Robots.txt. Google will read the text file and avoid the trap. Other nasty bots will fall into it. Since google will avoid our trap, I would also use option 2 and filter out Google's User Agent String from the stats.
The amount of real users should be basically the same number as the number of real users - bots. If you want to you can check the User Agent which will tell you who is browsing the site.
You could try out my tracking script, it's pretty simple to implement and bots and spiders will come up as a bunk browser so it's easy to weed them out. I use this on all my company's sites for analytics. There's one caveat though, if you use this for keyword tracking you may be disappointed real soon because Google is starting to change the structure of their query strings for logged in users.
https://github.com/k4t434sis/tracking.php
I've been tasked to build a system that allows someone in our company to send out an email with a link to a pdf file that will be kept on our webserver. The recipient can follow the link to view a newsletter we normally sell. The idea is we do this for three months, then see if they'd like to continue and pay for the full subscription.
I've got the registration portion built, but I'm trying to find the best solution for sending the email. Here's what I've thought of, but am interested if anyone else has something better..
1) When emailing, generate a generic code that gets appended to the URL. The use would follow the url, and it would check our DB for "ok" entries and pass/fail them access. This seems ok, but a link could be passed around or even loaded to a public site where anyone could access.
2) To extend the above, I thought maybe I'd have a "one time click" kind of thing where once I know the link was clicked, it could expire, so any subsequent clicks fail. The downside is if they click to view and close their window, they're done. Likewise, if they click and their computer crashes before download completes, they'd be locked out as well. I don't know if there's a way (in PHP for me) to confirm a file download has completed...
3) I could put the files in a directory like /trials/201009/r#nDomstr1n6.pdf where the file is uploaded and the name for the link is random so it would be hard to guess. Then I could use .htaccess to protect each month's folder with a different password. This could get tedious and would be annoying for users most likely.
We don't want to force them to manage their own passwords b/c having to login and remember yet another account may discourage participation.
Thanks for any ideas or pointers.
D.
I'd say do it with a random code for authentication per email address, and expire that after 5 days. If you limit access to the ip that first hit the url hash, that could work too but could iconvenience legitimate users/customers.
In any case make it easy for legitimate users to request a new authentication code if needed. That way even if any of your limitations inconvenience one of your potential customers, they will not be as ticked off about it.
Finally, consider that if they like the pdf and want to share it, they will probably just share the pdf itself right away and not bother with a link.
First off, realize that there is only so much you can do here on your end. You are allowing users to download a PDF, after which they can do with it what they please (legally or otherwise). So, preventing passing around the link is not necessarily going to prevent people from sharing or posting the PDF itself.
That said, if you do want to make it a little harder, you could do a variation of your suggestion #2 in which you institute a time delay of some kind before the link expires after it is clicked. You could also limit the number of times the link will serve the file. Because people have a variety of connection speeds, and because I do not know how large your PDFs are, I cannot say for sure what the time delay should be if you choose to use it.
Like I said, though, if someone is determined to share the file, they can easily do so.
Another possibility is that since you already know the persons email address, form a specific url for them in their email link.
So a user would click a link http://www.yourdomain.com/download_pdf.php?email=person#test.com
Keep a table with the following data for the email addresses.
id
email_addr
read_date
expire_date
When they click the link check to see if they've read it before and if they have check it hasn't expired. If it hasn't, serve the pdf to them, if it has give them a page that says "Sorry, your trial has expired../"
If its their first time clicking it then set the read_date and calculate the expiry date and set that.
Or optionally you could generate a hash or something and use the hash to id the user instead of their email address.
You could also set up a download column int he table and stop them from downloading it more than twenty times or something by incrementing the download column every time they click the link.
I was trying to do subscription system which is only for registered user. Till registration stage, I am okie. But I don't want user to share their username and password with others because of the paid content. How can i prevent ?
Check with IP, but what if they are on dynamic IP ? Using proxy ?
Store cookies can change ?
Can anyone please kindly suggest how can i prevent ? I know there's no 100% bullet proof, but somehow, alittle bit tight security system.
Language will be with php, mysql, javascript.
I recommend heuristics based approach -- if you detect something suspicious (eg. user connecting from many different IP-s) then you log this and this increments some counter in users's record, if the counter grows big enough, then you get notification and decide what to do.
It won't eliminate all cases of account sharing but hints you the problem users.
when your content is payed content, tell the users that they have to enter ther credit card informations every 10th login. I think this will stop them to share account. (When CC informations are wrong, the account will be closed).
Other idea: Limit the Sessions for one user to 2 - 3. They will think twice to share their credentials if they are not able to login when their friends are connected.