[semi-OT]simulating onSubmit in post

[Jim Ault]

On Feb 23, 2010, at 3:11 PM, Devin Asay wrote:

> Hi folks,
>
> I'm trying to teach myself how to GET and POST submissions to URLs  
> that provide simple web services, like word lookups and the like. I  
> understand the basic concept pretty well and can successfully  
> "harvest" data from various web forms. But I notice that often POST  
> method forms use JavaScript calls to validate data in the forms  
> before submitting it to the server. It might look like this:
> <form method="POST" action="someurl.htm?loadpage" name="formname"  
> onSubmit="return Validate(this);">
> In this case the Validate function is defined in the header and  
> basically returns true if the submit came from the form "formname"  
> AND all of the fields are filled in. It returns false if either of  
> these conditions is not met.
>
> My question: Is it possible to construct a post command and/or  
> header combination that simulates this onSubmit event returning  
> true? This is basically an academic exercise to help me understand  
> how JS and forms work, and how Rev's GET and POST functionality  
> works; I'm not planning to distribute stacks that do this in any way.


First some tidbits to think about in order to answer your question  
(skip to the last couple paragraphs if you wish)
When a web page loads, it is like a stack opening in Rev.
Events trigger 'messages' (function calls) that load CSS code, the  
results of PHP code that runs on the server, JS functions, and many  
others.
Some JS functions will run 'on openstack' and set variables (like Rev  
'globals') which remain available as long as you stay on this web page.
Some JS functions are in memory and get triggered on mouseup,  
mouseEnter, mouseLeave, click, openfield, closefield, etc

Using FireFox and the FireBug add-on, you can see all of the scripts  
that are loaded in a broswer, and debug them step-by-step if you  
wish.  FirePHP can do the same for php scripts.

Because of security rules and conventions to protect server attacks,  
user-browser-globals are not a good thing to be kept between pages, so  
the site programmer uses cookies (client-side) or session variables  
(server-side) as a tracking mechanism.  Many users add functions to  
their browser to make it more secure and these detect web pages that  
try to run malicious scripts or keep globals from page-to-page or do  
pop-ups, etc.

And now on to forms.

Form validation can be programmed by the web guy a few ways.  The  
slowest is to have the FORM submit data and the server script do the  
work (server-side), returning a result to the browser and causing a  
reaction accordingly.  The fastest is when the page is programmed with  
JS that does the same work on the local machine (client-side) because  
the server is not involved.  A third way is to be using AJAX, which  
interacts with the server-side script after each keystroke (eg. Google  
search suggestions as you type).

Simulating 3 types of forms:

server-side FORM
The way I use is to go into FireFox, activate the add-on using menu  
Tools:Live HTTP Headers, fill in the form, then capture the headers  
that are send by the browser.  The headers will include the GET and  
POST data (of course).  Now you can use Rev to manipulate the Headers  
(see the Rev dictionary) before submitting a form.

client-side JS
This step is done locally and usually only sends data to the server  
when there are no errors.  If there is an error, the JS usually  
modifies the current web page indicating the corrections required.   
After all errors are fixed, the submit will allow capture of the  
Headers and you can see the GET/POST variables

AJAX server-side
This is a system of calls to the server triggered by some event, such  
as keystroke and blur/focus changes, so that the users input triggers  
changes in the web form.  This is commonly used in airline and hotel  
reservations pages so that dropdowns and options trigger the  
appropriate form values for the user (eg. discounts available, seats  
available, rental car packages, black out days)  Again, Live HTTP  
Headers can be used to capture, but now you will have numerous events  
to compile by reading the headers sent and received by the browser.   
You can choose to save a log of these transactions and study them.   
The downside is that you will not know all of the variations until you  
try them on the web page (eg. airline ticketing and flights available,  
a calendar that starts with today) because they are dynamic conditions.

The first two are easily simulated with a Rev post command,
but the third would require using the form, and scripting some arcane  
variations to test the return values.

One way of capturing the GET/POST variables using Rev is to change the
   action="someurl.htm?loadpage"
to your own Rev cgi/OnRev script and parse the headers and variables  
yourself, but I find Live HTTP Headers more convenient for sleuthing,  
especially Authorization headers.

By the way, Live HTTP Headers should work just as well when you are  
browsing  ( myaccount.on-rev.com/someURL.irev )  since the browser is  
using the same protocol to interact with the OnRev server.

Your specific question was
My question: Is it possible to construct a post command and/or header  
combination that simulates this onSubmit event returning true? This is  
basically an academic exercise to help me understand how JS and forms  
work, and how Rev's GET and POST functionality works; I'm not planning  
to distribute stacks that do this in any way.

You could modify the
<form method="POST" action="someurl.htm?loadpage" name="formname"  
onSubmit="return Validate(this);">
replacing the function call result rather than making the local JS  
call Validatate(this) - which resides in the browser RAM (just like a  
stack script in Rev)
<form method="POST" action="someurl.htm?loadpage" name="formname"  
onSubmit="true;">

In most cases, the server-side script will also do error checking (or  
at least it should) and in this case the programmer decided on local  
error checking to decrease server load and provide faster response for  
the user.

Hope this helps you


Jim Ault
Las Vegas