[Tutor] Design suggestion - is a cookie the answer?

[Alan Gauld]

> I'm sure this is implied in Alan's post, but I'm going to point it out
...
> To avoid further cheating you might want to sure there is no way to
> submit the form without javascript turned on. E.g. Don't have a submit
> button and a form with an 'onSubmit' validation. Which some examples
> do use. Otherwise, they can just turn off Javascript support in their
> browser and bypass your validation.

Nope that wasn't implied in my post. I confess I just rely on 
JavaScript being there. But your point is a good one!

> way of doing it, then so be it. Will the URL intervene in just
> presenting a URL to the browser? 

The onValidate technique just does a check before sending 
and if it returns false doesn't send. The onClick method 
actually requires you to explicitly submit the form to the 
URL, that's why it's more secure.

> One of the 'cheats' was just putting the cursor within the 
> URL bar and then pressing enter. Does Javascript
> pick this up as well?

No. JavaScript is an event driven paradigm and it only 
picks up the explicit events you register with it(*). One of 
the problems of using CGI is the ese of frigging it. I assume 
you are using GET instead of POST? GET is the default 
submission method but POST is nearly always better and 
should avoid the problem here. (I think, I haven't tried it!)

(*)Not really true it will execute any inline code too.
But it won't trigger to events that have not been registered, 
like a direct address refresh.

On the subject of JavaScript being the *right* solution
it ois of course only one way to do it. You could add code 
in your CGI that simply checks that all answers are filled 
in before responding, but that means a longer delay in 
response. In general where you want to validate that a form 
has been filled in its a better user experience to do it in 
the browser and that means JavaScript.

HTH,

Alan G
Author of the learn to program web tutor
http://www.freenetpages.co.uk/hp/alan.gauld