First of all; I'm aware that this question is strange and I will probably get a lot of downvotes for it, but I still need some more information...
Here's the problem; The company I work for maintains a webshop (PHP, MySQL, IIS). The webshop is going to give a discount to people how came from some other, third party website. After logging in to the third party website, the users are presented with a static link to the webshop (the link can contain some sort of code) [UPDATE we can provide the link, that's all we can do, we have no privileges whatsoever on the third party server]. If they use that link to go to the webshop they have to get the discount. If a user uses another link, or goes to the webshop directly the shouldn't get the discount.
I was thinking of using PHPs HTTP_REFERER to check if the users comes from the third party website, but that is not reliable. Is there another way to make this a bit more secure? I'm aware that we won't be able to create something that makes it completely safe, but we should at least do something that keeps the user from posting the link to a forum or sharing it by e-mail.
I hope you can help me, please don't burn me down for having to implement the request of a customer. I know this is stupid, I just need to do it and I want to do it in the best way possible.
...we should at least do something that keeps the user from posting
the link to a forum or sharing it by e-mail.
Not really. The best you can do is use a combination of HTTP_REFERER and a secret code embedded in the link, but the former is simple to fake and the latter is simple to copy. You're essentially asking to publish a phone number without letting anybody know what the phone number is.
Edit: If you've got some influence over the remote 3rd party site, you could make a joint agreement to change the secret code on a regular (daily?) basis. Or better, if you can both do this programatically, then you can set the code expiry to a very short time (e.g. one minute) -- this would make forum postings useless.
First of all, I don't think it's a stupid question at all :)
The HTTP_REFERER approach doesn't sound too bad.. You're right it's not completely waterproof, but you have to rely the user's browser to tell you where he's coming from anyway - there's no other way. I'd say a combination of a special link and checking the HTTP_REFERER on your end should do pretty good.
Have the link call a javascript function that forms a url to your PHP script that passes the window location href as a parameter. Then in the php script, test that the href matches the expected origination point.
Here is a suggestion:
Your affiliate-site generates a unique-string which is embeded in the link to your site.
$link=md5($_SERVER["HTTP_USER_AGENT"].$_SERVER["REMOTE_ADDR"]."Very secret string");
echo 'Claim your rebate now!';
On the receiver side:
if($_GET["ref"]==md5($_SERVER["HTTP_USER_AGENT"].$_SERVER["REMOTE_ADDR"]."Very secret string")){
applyRebate();
}
Related
I want to create a private url as
http://domain.com/content.php?secret_token=XXXXX
Then, only visitors who have the exact URL (e.g. received by email) can see the page. We check the $_GET['secret_token'] before displaying the content.
My problem is that if by any chance search bots find the URL, they will simply index it and the URL will be public. Is there a practical method to avoid bot visits and subsequent index?
Possible But Unfavorable Methods:
Login system (e.g. by php session): But I do not want to offer user login.
Password-protected folder: The problem is as above.
Using Robots.txt: Many search engine bots do not respect it.
What you are talking about is security through obscurity. Its never a good idea. If you must, I would offer these thoughts:
Make the link expire
Lock the link to the C or D class of IPs that it was accessed from the first time
Have the page challenge the user with something like a logic question before forwarding to the real page with a time sensitive token (2 step process), and if the challenge fails send a 404 back so the crawler stops.
Try generating a 5-6 alphanumeric password and attach along with the email, so eventhough robots spider it , they need password to access the page. (Just an extra added safety measure)
If there is no link to it (including that the folder has no index
view), the robot won't find it
You could return a 404, if the token is wrong: This way, a robot (and who else doesn't have the token) will think, there is no such page
As long as you don't link to it, no spider will pick it up. And, since you don't want any password protection, the link is going to work for everyone. Consider disabling the secret key after it is used.
you only need to tell the search engines not to index /content.php, and search engines that honor robots.txt wont index any pages that start with /content.php.
Leaving the link unpublished will be ok in most circumstances...
...However, I will warn you that the prevalence of browser toolbars (Google and Yahoo come to mind) change the game. One company I worked for had pages from their intranet indexed in Google. You could search for the page, and a few results came up, but you couldn't access them unless you were inside our firewall or VPN'd in.
We figured the only way those links got propagated to Google had to be through the toolbar. (If anyone else has a better explanation, I'd love to hear it...) I've been out of that company a while now, so I don't know if they ever figured out definitively what happened there.
I know, strange but true...
I have an interesting problem to solve here that may require some creative direction. I have a PHP page which has a variety of different page outcomes depending upon which value is passed through the web browser. For example:
http://examplesite.com/landingpage.php?id=one
http://examplesite.com/landingpage.php?id=two
http://examplesite.com/landingpage.php?id=three
With the current set-up, each of these pages has a different offer for the site visitor. Here is the catch...
I only want the page available to the visitor once per session.
That seems like it would be easy enough, but I cannot make it work right. I have used a one-time offer script to submit a cookie which then re-directs the user to another page if they have already viewed the offer, but that did not work for this situation. It will work fine for one landing page, but it is based on the root PHP page so if any of the other values are passed it will re-route the user even though they have not seen the offer.
For example, if a site visitor goes to:
http://examplesite.com/landingpage.php?id=one
they will see the one-time offer. Then, if they go to:
http://examplesite.com/landingpage.php?id=two
They will be re-routed as if they had seen the offer for 'two' which they had not.
I hope this issue makes sense. If you need further clarification, just ask. Thank you for going through my problem and if you don't have the exact answer, but can point me in the right direction it would be much appreciated.
Without looking at the code for landingpage.php, I can only guess that you are not factoring in the id when you check for the existence of the cookie. You need to set cookies on a per-id basis. Otherwise the behavior you see will occur: viewing id=one will set a cookie and when the user views id=two, landingpage.php sees the cookie exists and redirects the user.
If you want to keep it simple enough, you can just have your cookie be a string of id fields delimited with a character such as a pipe or comma: viewed_ids=one,two,three. Then you could parse this to see if the id of the current page is in the list of viewed ids and redirect the user if it is, or add it if it isn't.
I am sure you realize that maintaining state in the session can be easily worked around by the user, since you mentioned you only need this redirection to occur on a 'per-session' basis.
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.
Is it possible to get remote username when I get a referral link without involving any server side code from the referral link?
Do you mean like if I clicked a link to your site on Stack Overflow, you would want to be able to see that my username is "Agent Conundrum"? No, you can't do that without the help of the referring site. The only information you should be able to get is the (permanently misspelled) HTTP_REFERER in the $_SERVER superglobal array, which tells you the page the user came from. Even then, there are ways to block or change this so you shouldn't count on it being set (especially since it wouldn't be set if the user navigated directly to your page via the address bar).
Frankly, I wouldn't want to use a site that leaked personal information (and for some sites, even the username qualifies as personal information), and I wouldn't want to use a site that tries to harvest such leaked information without my knowledge.
Generally, any site where you have a legitimate reason to broadcast this information would have some sort of API built in, like FacebookConnect. Even then, it should be strictly opt-in for the user.
As a general thing: no. The HTTP protocol does not involve the transmission of a remote user name.
Hey, it could help to answer if you would be a little more specific on which kind of service are you trying to fetch the data from.
Large/Public services tend to have somekind of an accessible API that you can fork on your referrer, but other than that its mostly that you need to regexp the site and know the structure of the HTML pretty much.
My adsense ad have a dedicated land page.
I want to show the content only to those who came through that ad.
The page is coded with PHP so I'm using $_SERVER['HTTP_REFERER'].
Two questions here:
Is there a better alternative to $_SERVER['HTTP_REFERER'] ?
To what strings/domains should I compare the referrer's domain (I'll handle extracting it)? I mean, I'm guessing that google has more than one domain they're using for the ads, or not? There's doubleclick.com.... any other domain? How can I check it, besides try/fail?
$_SERVER['HTTP_REFERER'] is the canonical way to determine where a click came from generally. There are more reliable (and complicated) methods for clicks within a site you fully control, but that's not much help for clicks from Google. Yes, it can be spoofed, and yes, it can be null, but as long as you're not targeting nuclear weapons based on that data, and you can handle null values gracefully, it should be good enough.
As for domains, you have to consider the international google domains, as well as all the google*.com domains.
I suggest adding a parameter on the link you give to Google. i.e. instead of yoursite.com/landing, do yoursite.com/landing?campaign=12.
If you are concerned that curious users will play with this parameter, the fix is simple-- redirect via a server 301 redirect when they hit that URL.
That is, if I request yoursite.com/landing?campaign=12, your server--before serving a page-- should log my visit to campaign 12 and redirect me to the plain url yoursite.com/landing. This has the added advantage that reloads won't increment your campaign hit count.
Yes, users could still mess with the original link if they are clever or curious enough to look at it before they click on it, but I think this is going to be far more effective than sniffing the referer.
Rather than trying to work out on your own how to measure your page views, you can consider using an existing system for that, like Google Analytics