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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
