Form submit to iframe on new page - forms

I have a form which submits to an iframe, This works fine if you are on a page with the iframe.
I want to be able to have the form on any page and when submit is pressed load a page and send the submit to the iframe
e.g.
On page "article.php" and press submit
Open page "results.php" and
Send post data from form clicked in "article.php" to iframe "DataHere" on "results.php"
Thanks in advance

You could try detecting if the frame exists when the form is submitted and if it does not, reload the whole page and generate the iFrame.
If you need a hand checkout http://www.java-scripts.net/javascripts/Check-Frames-Page-Script.phtml

If you are able to comfortably sanitize your initial POST data to avoid XSS, you could create an intermediate page for your iframe destination that does your POST for you:
On page article.php with <form action="results.php">, press submit.
results.php validates that the input isn't XSS, and renders with a <iframe src="negotiator.php?my=form&data=here"></iframe>
negotiator.php takes the query string arguments (and runs the same sanitizing as results.php) and POSTs them to your intended url.
Your results will load in the iframe.
It's pretty important that you make sure your input isn't insane. If your form requires arbitrary text, punctuation, and special characters, this is not safe for you.

Related

Wicket: Loosing form input on page re-render

I have pages with forms. Everything is working fine. Except, that there is a link (language selecter) on the pages. The requirement is, that when the user has already input in the form fields and than (without submitting the form) is clicking the link, all input should be retained.
If the link would be part of the form, this could easily archived via a SubmitLink and submitLink.setDefaultFormProcessing(false);
Unfortunately, this link has no knowledge of the form(s) on this page.
Any pointers if this is solvable? Of course, validation should not be triggered.
client-side JavaScript solution
wrap complete page content in a form
(yes, Wicket allows nesting of forms) and use an SubmitLink with
defaultFormProcessing=false
add an AjaxFormComponentUpdatingBehavior
to all your form fields, so the input is always sent to the server

Auto send form (JSP) and load page in iframe

I have a page (jsp) with a form and a submit button. After clicking the button the form data is posted to another JSP that creates the output (a table with links).
My problem is, I need to do this AUTOMATIC, I can fill the form via url GET thats not the problem but how can I force the post to that other page without clicking a button. I want to include the result (table with links) on another page (with php or just iframe) so the result has to be generated when the page is opened.
I CAN NOT change any of the JSP pages, they are part of a closed system which I can't change.
Thanks...

How can I render a completed CGI form as a PDF?

I have an HTML form which a user may have filled in or partially filled in. I want to snapshot that state and render it as a PDF document. I've been using wkhtmltopdf.
I've tried this from both the client side and the server side, and the rendered result is always the original form, never the filled-in one.
I notice if I reload the filled-in form page I get back the filled-in form, but if I cut and paste the form's URL into a new window, I get the initial, non-filled-in form.
So I've convinced myself that, if I could use CGI::Session properly, I could successfully open a session identical to the filled-in session. I tried using CGI::Session::Plugin::Redirect with no joy. I think the key is that window.open() has to use the SID of the filled-in form window.
I don't have a lot of experience with CGI session management, so this has been a four-day quest to nowhere. Any advice is appreciated, even if it's to abandon this approach and go back to the more common post->render a new form in a new window, and generate the PDF from that. I'd like to avoid all of that if I can.
Say you have the following HTML document on your web server:
/var/www/html/index.html
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<form action="/process.cgi">
<input type="text" name="foo">
</form>
</body>
</html>
When you navigate to http://hostname/index.html in your browser, the webserver returns this document and the browser displays it.
When you fill in the text field in your browser, the document on the webserver doesn't change. So anybody who navigates to http://hostname/index.html will get the original, unmodified form. This is why you can't simply copy and paste the URL into another browser tab and get the filled-in form.
Most browsers use caching by default. When you fill in some fields in a form, the browser caches what you entered. When you reload the page, the webserver sends the exact same document as before* (i.e. the unmodified form), but the browser uses the cached data to fill in the form fields the way you had them. If you override the cache when you reload the page (Ctrl+F5 in Firefox), the form fields will not be filled in. Note that neither the URL nor the document on the server have changed. This is why you can't copy and paste the URL into another browser tab after reloading the page and get the filled-in form.
wkhtmltopdf takes a URL, renders the corresponding page, and generates a PDF based on what is rendered. Based on the explanation above, it should now be clear why wkhtmltopdf always generates an image of the unmodified form.
The solution
If filling in form fields doesn't change anything on the webserver, what does it change? It changes the DOM, a structure describing the document in your browser that you can access using JavaScript.
One approach would be to use a client-side JavaScript PDF generator like jsPDF; since it runs on the client, it has access to the DOM that the user is interacting with, so it can "see" the values the user enters into the form fields.
* Actually, the webserver will typically send a 304 Unmodified response to save bandwidth, but form caching works the same either way.
The explanation from ThisSuitIsBlackNot is accurate about why your design is failing. Typing characters into form fields in a browser changes only your screen and the data in the memory allocated to the browser.
I suggest a different solution. The WWW::Mechanize::Firefox module is a variant of WWW::Mechanize that uses a real browser application to retrieve and render web pages. It is mostly chosen when a site requires JavaScript support, but it is useful here because it has a content_as_png method which returns a PNG image of the current page. Hopefully that is enough for you to build a PDF file with the required content

How do I make a link that pre-fills a form checkbox?

I have a page called contact.htm with a working form. One of the checkbox fields on the form is named Garden (so either it is checked or not when using the form).
I have another page that I want to link to my form page, so that if a user clicks a particular link, they are sent to the form page and the field Garden is pre-clicked.
I have not been able to do this though I have tried several methods...such as:
a href="contact.htm?checkbox=Garden,on" or
a href="contact.htm?checkbox=Garden,checked" or
a href="contact.htm?input type="checkbox" name="Garden" value="checked", and some others.
I would appreciate any help.
You'll need to use JavaScript on the target webpage to process the argument and fill the values in. There is no automatic way of doing this just by URL.
This link shows how to retrieve URL arguments from JavaScript. From there, it's a matter of using standard JavaScript or JQuery to fill the values in.

Reload page from CGI?

I have a form that looks like this
<form action="/receiver.pl" method="post">
</form>
Clicking on the submit button doesn't take the user to a new page, because of some JQuery that can be seen here.
Is it possible in receiver.pl to reload the current page?
What receiver.pl is doing is processing some data that is shown on the current page, where the submit button is.
So it would be really cool if the page could be reloaded, so the changes could be seen right away.
Receiver wouldn't do that. What you'd do is this:
jQuery makes an AJAX call to receiver.pl
Receiver.pl does its thing and returns a valid JSON string to jQuery.
jQuery then reloads the page or alters the page based on the content of the JSON results.
The CGI itself cannot reload a page once it's already been loaded.
No. A server side process can only return data to the client. The client has to initiate reloading the page. This would normally happen when the form was submitted, but the JavaScript is intercepting that action and replacing it.
It sounds like the solution is "Remove the JavaScript that is stopping normal form submission".