It is a commonly used technique called anti-leeching or anti-leaching .
Search for "anti leeching php" or "anti leeching jsp" on Google. You
will find many resources.
You can control the path that a user takes by checking for the
HTTP_REFERER . But this is not a fail-proof technique, because the
HTTP_REFERER can alwasy be spoofed.
In Peace,
Saqib Ali
http://validate.sf.net
On Tue, 1 Mar 2005 10:19:37 -0500, Kevin Conaway
<kevin.conaway@gmail.com> wrote:
For our application, we would like to prevent users from requesting
application resources directly. E.g. browsing to
http://localhost/app/method.do?id=5&type=3 instead of actually
clicking on a link that the application provides.
We would like to do this without a major impact on our code. I was
thinking of using the following scenario:
- Currently we have tag libraries that help build all our URLS. These
tag libraries would be modified to include a strong cryptographic
token that is unique to each URL/User combination. - The token/URL
combination would be stored in the application context for a
pre-determined amount of time.
- Next, we would use a Servlet filter to intercept the URL. First,
deny URLS requested without tokens. If a token is passed, verify that
matches the token stored in the application context for the requested
URL.
For the token, I was considering using SecureRandom to generate a
random number and compute a hash of the random number and the URI
being requested. This would be stored along with with URI and the
user Id.
Could anyone point out any pitfalls I need to be aware of, or if I'm
going about things the wrong way?
Thanks
Kevin
--
In Peace,
Saqib Ali
http://tools.tldp.org/search.php <--- Search for Linux HOWTOs
