Killing The Browser Search History

[Merlin1857]

Hi, does anyone know how to programatically kill a browsers search history on exiting a web application. I am writing a complex ASP app for a company and to make sure that previously seen pages during a session cannot be recalled using the various tools which allow this in IE for example I would like a method which, if the user logs out properly will delete the entire bowsers memory.

[jhardman]

Hi, does anyone know how to programatically kill a browsers search history on exiting a web application. I am writing a complex ASP app for a company and to make sure that previously seen pages during a session cannot be recalled using the various tools which allow this in IE for example I would like a method which, if the user logs out properly will delete the entire bowsers memory.

I would venture a guess that you can't do this with ASP. possibly with javascript, but those things might not be allowed for matters of security.

You could certainly make it very difficult to find where previous users looked, for example by using only one page which based on user responses opens different include files, the user responses which lead to certain responses could all be kept on server variable so the browser itself would have no idea where it has gone. Does this make sense?

Jared

[markrawlingson]

Since history files are stored residentially on the computer's hard drive, My best guess at this would be some sort of activeX control. I believe that would be the only way to do it since activeX controls can actually interact with objects on the local drive - which is why spyware became such a massive threat overnight, and is also the reason why all current versions of IE block activeX content by default and notify the user so they can enable it if they want to or leave it disabled if they don't want to take the chance.

Languages such as ASP & javascript couldn't hope to do this on their own.. it's not built into their syntax because it's dangerous. The only way would be to use an object that interacts with the site visitor's hard drive if you wanted to actually add/delete files which is essentially what you're doing by clearing the history. Perhaps a .DLL or .EXE file - or activeX control. But outside of that... I would be surprised, scared, and appalled if you could pull it off without using anything outside of ASP/JavaScript.

[Merlin1857]

I would venture a guess that you can't do this with ASP. possibly with javascript, but those things might not be allowed for matters of security.

You could certainly make it very difficult to find where previous users looked, for example by using only one page which based on user responses opens different include files, the user responses which lead to certain responses could all be kept on server variable so the browser itself would have no idea where it has gone. Does this make sense?

Jared

Jared, Thanks for the reply on that, could you flesh it out a little more please.

Steve

[jhardman]

Jared, Thanks for the reply on that, could you flesh it out a little more please.

Steve

OK, say you have an online shopping site with sign-in page, catalogue pages, product detail pages, etc. Set them up kind of like frames within the main site, except put the individual pages in include files instead of inner frames. The basic page layout would be a large select case or if then else statement which would give the browser the different pages he could visit. The first case should be if session("userID ") = "" and the user should be referred to the log in page. The trickiest part would be to do all of the navigation by form submission sothat the data that determines which page you visit is never stored by the user (if you ever put info in a querystring, the browser will save this info as a different URL you visited, and that is what you are trying to avoid. If all of the info a previous user sent to the page went through forms with hidden inputs no info is saved by the browser except which page he visited, and if they are all the same ASP page the browser only registers the fact that it visited the one page multiple times). So after logging in I show the catalogue page, each item hyperlink (going to a product detail page) could actually set off a javascript function that enters this data in a hidden form field and submits the form. Hidden form fields aren't even filled in by auto-complete browser functions, so new users would never see those.

The drawbacks to this approach are 1- you will have very long, complicated code to do what is essentially easy stuff. 2- you would have to do it from scratch, this would be long and tedious to do for an existing site. 3- When a user goes to submit an order he may have to go to a form and see auto-completed information anyway, so all your effort may be for naught.

On the other hand, you could do very well by just checking for a session("userID ") at the top of every page, and if this is missing, send the user back to the log in page. If the session("userID ") is present, include a session identifier as part of the querystring in every single href attribute. (<a href="productDe tailPage.asp?pr oductID=43x1&se ssion=546271">L ace-up blue sneakers</a>) This way the browser will interpret each link as never-before visited even if you never use the session ID part of the querystring in your page. And if a user is not logged in, even if he sees a product ID in a querystring, if he tries to visit it in the cache he will be sent back to the log in page.

I'm starting to ramble, but I think this is a better option for most applications. Does this make sense? Would this work for you?

Jared