Limiting the Lifetime of URLs

Overview of a technique for scoping the lifetime of a URL to a fixed time period.

The ability to scope the lifetime of a URL for say 10 minutes came up at TechEd. Interestingly enough, I did something similar in the CAPTCHA control I use in my comment forms, so the generated code auto-expires and cannot be used for playback attacks. I thought this was a one-off scenario, but apparently not. In the attendee's case, he wanted to make sure those links could not be navigated to from Google search results.

Based on what I had done, here is what we discussed. Basically figure out a DateTime until when a URL is going to be valid, and encrypt it with something like the Rijndael algorithm from the System.Security.Cryptography namespace, and add that as a query string parameter. Now, on the target page, during OnInit (or perhaps even earlier in the BeginRequest event using a custom HttpModule), check for the query string variable, decrypt it, and redirect if the URL has expired. I am curious if there are there other scenarios people have for limiting lifetime of a URL, as well as other techniques. In discussions like these, I wonder whether there is a useful control scenario in the background. If ASP.NET had good extender provider support (hopefully in v-next), this could be implemented as an extender provider for the HyperLink and Image control.

Of course, I suppose, one should also prevent search engines from saving a cached copy of the expiring pages. I wonder if the robots.txt mechanism could be used to convey restrictions such as this, or to ignore a specific range of paths for search engines to consider. Is that possible?

Posted on Monday, 6/13/2005 @ 8:05 PM | #ASP.NET


Comments

8 comments have been posted.

Ayende Rahien

Posted on 6/13/2005 @ 9:15 PM
There is such a thing, it's called sitemap, and it's a Google Standard * that aids the search engine in indexing your site. One of the purposes is the expire unrelevant pages.


*Can you feel the flames if I would've said the same about MSN?

Aaron Robinson

Posted on 6/14/2005 @ 6:17 AM
Google honors a custom META tag by the name of googlebot, where you can specify that it shouldn't archive a copy of the document.

<meta name="googlebot" content="noarchive">

Sergio Pereira

Posted on 6/14/2005 @ 7:32 AM
I do use this kind of thing with dynamicly generated graphics urls, database stored file downloads (via ashx), and some other sensitive and resource intensive content that I may want to cache for a while. I also try to prevent users from sharing URLs that should not be shared.

Alex

Posted on 6/14/2005 @ 9:14 AM
I've seen this done before. I would recommend that developers and their clients think hard about use cases of their sites before taking these steps; for as much as you think your user experience forced from a single home page(s) this is often a wish thing imposed without thought by people who want a 'pure' site experience. Just the other day I googled ATI driver support and found a reference to an answer I wanted. On going to the page however, I found that I was autodirected to the ATI support home - not a good thing for me.

So while disposable URLs are a useful tool especially where security is a concern, care should be taken not to break legimate user scenarios search as web search entry into your site.

Bhasker

Posted on 6/22/2005 @ 12:14 PM
just my 2 paise.

I remember facing a problem with a custom fn that used to parse a web page (with http header etc)and save it .The logic was to then make the app read from the saved file. But, i had to make sure that the app wud konw when to realise that it was reading an obselete version of a cached file;or when to go back and make another parse attempt.

eventually it worked by replacing the valid url ,with an ?=123 or so ,so that the invalid url would trigger a fresh pasrsing process

LukCAD

Posted on 6/27/2005 @ 10:08 PM
Hi Nikhilk!
I had the same aim - to kill cash of loaded url. I used for refreshing images everytime next way: I added into end of name every image the carrent time via ?. Like this, for example: Image1.ImageUrl = "namepic.jpg?" + System.DateTime.Now;
I hope that i added new idea for you. (or may be you know it, then sorry...)
Sincerely, LukCAD

Nikhil Kothari

Posted on 6/28/2005 @ 8:37 AM
This isn't just about preventing the caching of content - its about prohibiting access to the content. Adding a time stamp that can be easily seen and modified defeats the purpose. If you just want to prevent caching, you can indicate that with the right HTTP headers.

LukCAD

Posted on 6/28/2005 @ 12:28 PM
I see. Yes, i use another way for preventing content. I make ID of parent page with special name, for example ADMIN. Then, when user place the url for authentificated page (for example he copied it for future), i will check not only IsAuthentificated page and not only cookie but i will check the ID of parent page also. If ID is not ADMIN then user can't get anymore secure information. You can check it into my MicroStore( lukcad.russia.webmatrixhosting.net/commercesql/ ). When you will login by nik@nik.com pass:0908 you will can possible press on sentence "Welcome Nik" to edit your personal information. You can save it url (of editing your personal information) then you make logOut. Try put the url for editing your personal information and you will see that empty page without it will appear.
Sincerely, LukCAD.
The discussion on this post has been closed. Please use my contact form to provide comments.