How to make a page not visable when direct url is typed?

I'm not an expert, but I believe this is known as 'deep linking.'

From wikipedia:



It is preventable - several sites I go to only allow links to their homepage - but I don't know how to code the prevention personally.

Cycloptichorn

Could you make that page say visitable only if someone had registered and then had to sign in through the page you want them to visit first?

Thank you for the responses. We are trying to stop users from typing a certain web site extension.
We do not want to add a login.
We are trying to figure out a way to code the page (page we don't want users to type direct) only to display if user came from certain pages.

Thanks

As you probably know, internet survers and browsers talk to each other using a protocol called http. The http requests coming from browsers would usually have a "referer" field that would indicate the page the user is comes from. Hence, if you have root access to the server, you could script it not to serve the request if the "referer" field is empty, or if it's the wrong url. That would not fool professional intruders, who could spoof the "referer" field, but would keep off your usual web user.

The details of your implementation would depend on your webserver (Apache, IIE, etc), your language for server side scripts, and whatnot. And even i knew those I couldn't tell you the details, because it's been a while since I've been mucking around with cgi scripting. But this is the general approach I would take.

Thank you thomas. That should work. Just have to find the coding for the "referer field". Hopefully someone might have the info and could post here..

thanks again.

Since you are using PHP, you should be able to use the variable that gets passed in $_SERVER['HTTP_REFERER']. If that is not equal to the sending page you want, you could abort. Search for "php referer" for more information.

Another way to do this would be to pass in a hidden variable from your main page. You could write a php line that says if the variable is not passed in then redirect to your main page, otherwise continue processing. If you count of the referer variable, you might run afoul of security software that hides the referer.

This link explains how to set up session variables in php: http://www.plus2net.com/php_tutorial/session-variables.php

The referrer header is optional, and many users have it disabled (for example common security products like Zone Alarm have blocked them at times). So this would be a solution that would err on the side of blocking users. Some users would have visted the first page but not be permitted to see the second page because their referrer was blank.

Another solution would be to set a cookie on the first page that you check for on the second page. This one will fail in cases where the user has their browser configured to not accept your cookie.

A third solution is a bit of a hack, it's an unintended way of checking what urls a user has been to. It works like this: Your browser is capable of displaying visited links in a different color than ones you haven't visited. So in this hack you check the color of the link with JavaScript and you can tell if it's in their browser history. Of course, if they have history disabled or cleared, or JavaScript disabled it will fail.

A fourth solution is to log traffic to the first page and check for it on the second page. For example, you store the IP address in a log when the user visits the first page, then the second page looks for that IP address (you can even save the visit time and have your code check for visit age if you want to control that). This solution will fail in cases where the IP address is very dynamic (e.g. AOL is a famous example of an annoying way to proxy requests where you may see IP change within a user's session as their requests begin to come from another caching proxy).


Off the top of my head there are no other ways of doing exactly what you want, so there you have 4 imperfect solutions. Because they are all imperfect I would recommend failing gracefully for usability. If you check for referrers the guys with blank referrers may not even know why your site is "broken" for them. You may want to include messaging to that effect so that the ones who are aware of their referrer being blocked can fix it. You should also note that the referrer can be spoofed easily (there's even a Firefox extension for it) so your efforts can easily be circumvented (though at a frequency where it may not matter).

Make sure to code smart, if you use cookies detect for them and display a message to the user telling them that a cookie is required to continue. If you opt for the referrer you are going to have a small percentage of your users simply never get to the second page so make them aware of why.

The JavaScript history hack is client-side so it can easily be circumvented by the user (e.g. turn off JavaScript) so it's not real security for you if this is critical (though the fact that you don't want authentication indicates that it is not).

Lastly, the IP logging solution is one that can mostly fail gracefully. Most proxies won't be dynamic enough to where IPs change every request so if you are doing something like redirecting to the first page they'll just have to click again. Thing is, some won't as they'll consider the redirect loop as a sign it's broken.

So here's my proposal for the ideal solution:

Start with the IP log solution, but also check for the cookie and referrer solution and if either of the other exists let them see the page. This way it only breaks if they: 1) have a rotating ip that changes mid-session 2) block your cookie 3) do not send the correct referrer header.

The advantages of this solution is that the situation where a user has correctly followed your sequence but still can't see the page is reduced as much as possible, which is good because that would be very annoying. The downsides are that they could spoof either the cookie or the referrer header to circumvent your requirement. Thing is, your requirement is just to visit a page, so it's as easy to comply with as to circumvent and it doesn't sound like it needs to be an airtight requirement.

And here's my proposal for a quick and dirty solution with the caveat that you are going to annoy some of your users:

Use the referrer check.

And on a final note, whatever solution you use will block most search engines. So that is something you should make sure to consider.

This is another good solution (as long as the use case can require that they visit the pages in sequence instead of one then the other at some unspecified time afterward). If a POST request instead of a GET request is acceptable it would not be as obvious as well. It's spoofable in the request in case that matters though. That is, if the problem is something like a rogue bot they could just incorporate the GET or POST variable in their requests.

So with that in mind, this concept could be secured by generating temporary keys. For example you create a random key that you insert in a database or log and include in the request to the second page, and the second page looks up the key in the database or log to check if it's still valid.

I think that is the best solution overall if the additional variables are acceptable for the use case.

My first thought was to password protect the final site and have the code in the linking page automatically provide the password to log the person in. If you don't go to the first page you can't access the second page without providing a password. Again, someone could get around it by finding the password in the code but a normal user wouldn't be inclined to do it.

It might be possible for the link on the first page to take you to an automatic login and redirect page that would never be visible to the final user.

If you are trying to stop 100% of users, I think you've got a tough task ahead of you, but if you are trying to stop 99%, I think some of the solutions above will work for you. If the idea is that people should visit your main portal first, I think 99% will work for you.