Archive of UserLand's first discussion group, started October 5, 1998.

Re: Secure Prevention of Deep Linking

Author:Jim Flanagan
Posted:8/11/1999; 9:00:41 PM
Topic:Deep Linking
Msg #:9371 (In response to 9320)
Prev/Next:9370 / 9372

A couple of posters and one private correspondent point out some flaws or special cases with the URL token scheme.

It breaks bookmarks. That's a feature! Did you ever notice how in a department store, you have to walk past all the expensive perfumes and jewelry and watches, etc. before you can get to the socks and underwear? Expose the returning user to more banner ads, and make them search for the content again, potentially exposing them to targeted banner ads based on the search.

Okay, cynicism off. This scheme is designed to prevent access to content in the face of uncertain availability of enabling technologies like cookies and referrer information. To enable long term access to content, use the enabling technologies. Cookies would work well for this. If the user accepts a cookie upon visiting the gateway, then the content server CGI lets them see it again (without verifying the token). Membership has its benefits.

It breaks media servers such as Akamai, arguably a prime target for such a strategy. Not necesarily--if the media server provider is in the loop.

If server G, the gateway server, and server M, the media server share the secret token, then G can generate the URLs and M can verify them. The rest of the information is encoded in the URL and the client's IP address.

It breaks proxies. This is a difficult problem in the case where a user's proxy server might change during the span of a session (as in the case of AOL). If the proxy changes for a user between the time the gateway page is generated and a request for internal content is generated, then the clientip will be different and access will be denied.

I don't want to spend too much energy defending the scheme, because I think the whole lawsuit matter is silly, and wanted to provide a concrete example of a simple and fast** way to restrict access to internal content.

** For the number of hits made to the demo page today, the calculation of MD5 hashes to generate the tokens probably didn't make a perceptable dent in my RC5 keyrate :-) For a more popular site, this might represent a more considerable amount of CPU power.

There are responses to this message:

This page was archived on 6/13/2001; 4:51:50 PM.

© Copyright 1998-2001 UserLand Software, Inc.