So the system I'm working on is using a complicated process to generate and display HTML forms, and an even more complicated process to handle these forms once submitted.
I want to be able to cut through the abstraction and just view, in plain text, the post-request that is generated by my browser when I hit 'Submit' on the form - the headers, the payload, everything - How can I do this? If there's a tool to make it easier to pick through, all the better, but if I can just get it in plain text that's fine too!
I realize this might seem like a very basic question, but I've actually never needed it before.
Thanks!
If you are using chrome hit F12 before submitting form,
then go to network tab -> Check Preserve log checkbox, and then hit the submit button, you can see the detail of your post request
Related
please may I have a little help I'm stuck not being able to google for a solution because of very common words.
There is a web page that uses POST to send data to a page on a subdomain when a button is clicked.
I need to recreate a button and send the same information.
My question is: Is it possible just by looking at the page (and the console??) when you click the button, to observer what happens and recreate/implement the same POST method?
Can I say for example: It does this, therefore I need this code to do the same thing?
Or is it not possible to reverse engineer? Will I have to seek help form the web page developer (not really an option in this case).
It is perfectly possible to inspect the request and reverse engineer this. You can use tools like the developer console in your Chrome/Edge browser (press F12), and tools like Postman to simulate requests. Also inspect the form and eventual javascript events attached to the button.
I found innumerable answers and explanations on refreshing after submit - how to do it, how to prevent it, etc. But I'm just wondering why all submit functions automatically reload the page? I would have thought the default is to not refresh, and there's an option for it, something like
<button type="submit" refresh="false">Submit</button>
Is this like an unspoken programming rule, or is there a reason to do with GET and POST requests or something of that kind?
Submitting a form is like clicking a link.
You send something to the server (when you click a link that's just a URL, with a form it is more complex data).
The server makes a response
The browser shows you the response
It would only "reload the page" if the server side code you wrote sent the same page back.
It's the normal behaviour because when you send data to the server, you usually want to know if it worked.
(The server could response with 204 No Content to avoid the browser loading a new page, but that would confuse most users because they would have clicked a button and nothing would appear to happen).
Can I use my HTML form to perform multiple actions?
Post the information to another destination.
Navigate a user to another page once they submit the form.
At the moment I can post the filled form to the destination but cant navigate the user to another page using HTML specifically. Is there any method in HTML to do this?
Any suggestions?
Things are easy if you control the server and/or are on the same domain, then you can do a server side redirect. But since you are using salesforce surely you don't control that. Nevertheless, double check their documentation for a redirect option you can put in the form.
If that fails, one thing I'd try is to submit it to an iframe: add <iframe name="foo" id="foo"></iframe> somewhere to your html (you can hide it too if you want) and add target="foo" to your form. Then, also add an onsubmit javascript handler to the form that redirects after a delay to allow the form to be processed. The timing of the delay is likely to be a source of bugs btw, checking for errors in the submitted form can't be easily done across domains, you'd be guessing. Maybe an onload handler on the iframe can do the redirect though, I'm not sure, but worth a try.
This isn't guaranteed to work either, some sites don't like being in iframes. If that fails, you might try setting target="_BLANK" to submit the form to a popup window then redirect your main window using javascript or something. This will require you to give an instruction to the user to close the window.
Lastly, if you can submit the data via a server side API call to salesforce, that would be good too because then the plain redirect option is back under your control.
You can use redirect after you perform whatever you are going to do on the first page (the one from form action)
Imagine that in a HTML file I have a disabled button. I might as well use Firebug to enable this button and so do the submission.
My question is: is there any way I disable this button and not allow this submission even when I modify the disabled property of the button in Firebug?
Should I always have to treat this problem on server side, thinking that this possibility could happen?
Yes, you should always validate server-side . The client-side validation is just to facilitate correction by the customer and provide interactivity with him, thus preventing him submit all data and only then discover the correct format or a missing field and then be forced to repopulate all the fields.
The form may have been easily incorporated into another web site and then the action of the form directed to your website or the user inject some malicious code/data in the form. (See: Wikipedia XSS )
Any malicious user can easily bypass a disabled HTML button to activate it by making Firebug or worse, even if you could prevent it, he can simply create an HTML page and point to your destination URL in the form action, or even without creating a page, make an AJAX request. He may even develop a tool for this using PHP with cURL (or sockets ) library or any other programming language like . NET using a WebClient/WebRequest or Java with HttpURLConnection which in both cases are exactly what a browser would do to request a page or send data to another... (And this task can be done in 5 minutes by any Junior Developer)
You should never rely on the user and should never consider client-side validation as a part of security flow, since by being client-side, any information from there can easily be manipulated as has exemplified above.
I'm creating a web page based on user input from a form. After the user sees the generated page I want to allow them to press the back button and make changes to the form. I would like to display the form as they had filled it out previously. What is the best way to get this behavior (with cross browser support)?
After the user sees the generated page I want to allow them to press the back button and make changes to the form. I would like to display the form as they had filled it out previously.
There is no need to add any clever fancy code; that is what browsers will do by default, unless you take active steps to prevent it, such as:
breaking the cache with Cache-Control/Pragma headers
generating the form page itself from the response to a POST (use POST-Redirect-GET instead)
generating the form elements from script
Cookie solutions are fragile and need special handling if you don't want two tabs open at once to get very confused. Make it easy for yourself: let the browser do the work.
JQuery has a nice cookie plugin which i used to keep exam data while the user browsed the site for the answers in place.
Store the saved information in cookies as delimited data. If the cookie exists, repopulate the form.
If you use document.formName.fieldName syntax, there are no cross-browser issues.
As a fall-back if cookies are disabled, you can store it on the server and do the same with AJAX.