How do I prevent redisplay of an HTML form?

[WebWitchcraft]

Hello, I'm putting the finishing touches on a new members website and have encountered what turns out to be a fairly common developer's conundrum... How to prevent the user (AFTER they have completed the payment screens and my registration page) from returning back to the registration page (using their back button) and registering again and again and again... I figured this would be an easy problem to solve by either expiring the page just displayed or by blocking the back button with a Java script, but cannot find any meaningful information on how to do either one of those things. I KNOW I'm not the first person to ever encounter this problem and question. What I would prefer to do is simply expire the page just displayed; but have no idea HOW to do that. Does anyone here have help to offer in how to keep the user from going back to an already completed registration screen?

For the record, my security mmanagement software does check for duplicate user names and email addresses, but that won't prevent a saavy user from entering a different user name and password. I'm picturing some college freshman here giving all of his dorm buddies a free membership to my site and eating up every nibble of bandwidth I can afford to buy!

I orignally posted this question to one of the other forums and after several rounds of "try this" and responding with "I already did that" someone finally suggested that perhaps my solution might be found here.

Perhaps I'm just being a bit dense here, but after 33 years as an IT pro,I don't really think so. I frankly consider the ability to recall a registration form to be a fairly serious security issue and I'd really LIKE to find a way to prevent that.

I have done quite a bit of web research on this topic and it seems to be a fairly common issue without a good documented solution. And so far, no one has yet been able to point me to a single site or a document where I can actually SEE how the "expired form" trick is done. Yes, I HAVE seen the expired forms that pop up when You hit the back button, but I can't for the life of me figure out what the heck the developer is DOING behind the scenes to make those expired screens appear and looking at the expired-forms after the fact is a bit like trying to figure out the license number of the truck by examining the entrails of a dead dog in the middle of the highway.

Java scripts have also been suggested and tried, but even that doesn't really work if I try hard enough to get past them with the back-button.

I am currently using the redirecting form trick and I'm even redirecting several times to make it harder for the user to get back to that form, but even that doesn't prevent them from getting there if they try hard enough.

HELP! I'm really stuck on this one!

Thanks...
TG Platt
Web Witchcraft Publishing

[HumanClay]

Use cookies?

[WebWitchcraft]

Yes, I'm afraid that that may end up being the only remaining option... although even that is imperfect. Still, it seems better than the other alternatives and when used in conjunction with the redirect and the double check in the Security Management software for duplicates, it may prove to be another link in a still rather weak security chain.

Frankly, I was hoping there might be another method, but I'm beginning to have my doubts...

I'll give it another day before I make my final decision and see if any other thoughts or suggestions surface.

Thanks for the "helpful hint",
Web Witchcraft

[freakysid]

I'm not so crash hot at HTML. I remember reading something about there being absolutely no way to stop Netscape Nav 4.08 from caching form data. Anyway, this would be a good place to look around. I'm visiting this site for the first time right this minute.

http://www.web-caching.com/

I believe the standard meta tags are:

<meta http-equiv="Expires" content="<today date> <time now> GMT">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache">

But I'm sure that they are not bullet proof Also - I guess it would be preferable to send these as headers rather than in meta tags. ?!?

[Skunk]

Don't rely on cookies and don't rely on Javascript for this one. This is a security issue - you don't want malicious users signing up lots of accounts. If you try and stop them with javascript they can turn it off, try and stop them with cookies and they can delete their cookie. Client side solutions should never be used to prevent malicious use as it's way too easy for clued up users to bypass.

It sounds to me that you've got a problem at a lower level. There shouldn't be a way for people to sign up for more than one account without paying for more than one account. Obbviously you are limited on this by your ecommerce colution, one popular way of getting round this kind of scenario is to ask for people to sign up for an account BEFORE taking payment, then the payment processing bit asks them for their username / account number and "enables" their account once they have paid. Then you just have to make sure they can't enable more than one account once they've paid.

[WebWitchcraft]

The time that I was implementing this solution, it was over the long Labor day weekend and the vendor I purchased my security software from was nowhere to be found. So when I saw that they had set things up assuming that the user would register for a user-id and password FIRST and pay for it afterwards, that seemed entirely bass-ackwards to me. So thinking I knew better than the twenty-something programmers who built the Security Software, I turned the entire process around the other way and required the user to pay first and register afterwards. THAT as it turns out in retrospect was apparently a very BAD decision. It's humbling but still nice to know that at age 50 I can learn a few things from a twenty-something every once in a while. B-)

After a few days of looking for a solution to my self-created dilemma, It now appears as though I may be forced to go back and spend a couple of days turning the process back around again and THEN figuring out how to confirm that the user has actually PAID before I allow them to access and use their new account.

I guess I'll just take this as a hard-knocks lesson regarding the fact that we 50-somethings aren't necessarily as all-knowing as we tend to think we are!

Sigh...

Thanks a lot for the feedback. It sort of confirmed what I had already been thinking... but it was still good to hear it from someone else.

If there's no solution by tomorrow, then I suppose I owe all of the twenty-something programmers out there a MOST humble apology; because I'll be forced to admit that the solution devised by the twenty-somethings was correct after all... Of COURSE I should let the user sign-up for their account and get a password before they pay for it rather than after!

Egad, what convoluted solutions these systems we build force us to create.

Thanks Again.

Web Witchcraft Publishing