What is the best practice as such? I have an iframe with a form and when it submits it updates the parent page. Currently it sends the form contents via GET so the parent page url reflects this. I can do the same via POST, but am wondering if this is frowned upon and if sometimes this is blocked/ unuseable.
Any help and advice is welcomed
There are no problems caused by using POST across domains (at least none that you wouldn't get from using POST on the same domain or GET on a different domain).
There is no problem submitting a form to a different domain, unless via javascript.
One concern to keep in mind is validations. You would want to take care on what happens when the form has errors, as you wouldn't want them to loose the information they've typed in if they missed something like 'name'. The server should be the final line of defense for validations, but you'll want to make sure that the client side validations for your form match those of the server and appropriately notify the user of their (or the server's) mistake.
The other thing that could potentially block a form from submitting over post would be a form that requires an authentication token. These are used by many different frameworks to prevent CSRF (Cross-site request forgery) attacks and ensures that the form was submitted from the same website domain.
Related
I am building a web app that contains a form. Currently, the user enters data into this form, which is saved in my database. Then the user opens a 3rd party website where it enters a subset of the exact same data into a form on that website.
Ideally, on submitting the form on my website, I would like to open the 3rd-party website in an iframe with its form prepopulated with the data already collected from my form. The obvious goal is to prevent the user from having to enter this same data twice, first on my form and second on the 3rd party form. Another benefit would be the lack of focus from my site as the user would need to complete additional steps after submitting the form on the 3rd party site.
I know that there are ways to prepopulate forms on other websites. For instance, Google Forms allows for forms to be prepopulated by passing values to the corresponding inputs' name attributes in a query string. Here's an example I created to demonstrate this (notice the query string.): https://docs.google.com/forms/d/e/1FAIpQLScqua9AJLvRgCuH8o-XfAGeZcbue9ND7a4z2JM5EcAuVqAwag/viewform?vc=0&c=0&w=1&entry.2020941857=Whatever+and+whatever&entry.473490210=foobar
Unfortunately, the "target" website does not appear to handle the incoming GET requests in a similar manner, which obviously should come as no surprise. Of course, it can't always be that easy. I can't even manipulate the values of the inputs in the target website's form by manipulating the DOM using Chrome DevTools (not that I would have any real understanding how that would help me even if I could).
Furthermore, the form doesn't even submit using an action attribute. Instead, here are the form and button elements that I admittedly don't understand (omitting some attributes for brevity's sake):
<form name="theForm" ng-submit="submitForm(theForm.$valid)"
no-submit-on-enter="" novalidate="">
<button class="btn btn-full ng-binding" type="submit" id="send-form"
track-event="{category: 'theFormSubmit', action: 'clicked'}"
skip-click-tracker=""> Submit </button>
</form>
I have also tried using DevTools to watch the headers as I submit information using the form. The headers don't appear to change when I click the button. In fact, there appears to be no activity at all in the Network tab when I click the button. I don't see any "Form Data" at all. But it's possible I'm misunderstanding what I'm seeing.
For what it's worth, it appears that the target relies heavily on Angular.js, which I know practically nothing about, so I'm not sure if its even relevant. I also am aware that iframes cannot be manipulated by javascript on my site unless it is of the same domain, which it is not. I briefly looked into phantom.js, but (from the little I understand) it appears that there would be an issue with maintaining the user's session on the target site. A reload would be required which would wipe out the prepopulated data defeating the entire purpose.
Anyway, I'm left wondering if there is some way to achieve my goal using PHP curl or really anything. As a side note, in case it is not already obvious: I do not have access to the full source code of the target website nor will I likely be able to obtain access to it.
UPDATE:
Using DevTools Network Tab, I again tried submitting the form with one of the inputs being the first name of Jude. I was finally able to isolate the header that contained the information by filtering by "Jude". The redacted header info and request URL are below:
I feel like I am finally getting somewhere. Based on the above, I feel that I might actually be able to submit the form data to the 3rd party website (sidestepping the actual entering and submitting of that website's form). Because I was using the UI, I could see that the form was submitted successfully, and I had visual cues for how that information was being dealt with. However, the HTTP 204 header (No Content) seems to indicate that if I send the information programmatically, there will be nothing returned for me to analyze success or failure of the form nor how the information is being dealt with. Ultimately, in the end, this may all be a red herring regardless because I am not sure how I would deal with the browser_session_id part of it anyway.
If you are using an iframe you might be out of luck, since browser cross origin policies will deny your JavaScript from tampering with the DOM in the IFRAME.
If the target website is simple enough, you can proxy over the whole form request and responses, cookies, and headers thorough your server (especially if you are using PHP) and then you are free from cross origin problams since the browser will see them as one origin
then you could access the iframes DOM
window.frames[0]...
or the anguler scope using
angular.element("#appname").scope()
I am a little new to PHP, and I have gotten in the habit of creating a specific file that handles all the form processing.
For example, I have one PHP file that displays the actual form, let's called it "registration.php" for example, and it specifies as its action "registration-process.php". A user fills out the registration form on registration.php, hits submit, and the data is POSTed to registration-process.php because it was specified as the action file by the form.
Now my question is this: Can't someone who knows what they are doing POST data to registration-process.php without going through registration.php? This would have the potential to lead unexpected consequences.
Is there any way to ensure that registration-process.php will ONLY accept POSTed data from registration.php? Like maybe a hidden field with a value that gets encrypted via some PHP code, and that value gets checked by the registration-process.php file? I wouldn't know how to do that, however, or if that's even the best solution.
Yes, using a hidden "security token" field is a common way to verify a forms integriy. Many public forums are using this method.
Try Google for php form security token or check out this site:
http://css-tricks.com/serious-form-security/
Can you only accept POST data from one location, probably. It is worth it, probably not.
As long as you are validating your form fields correctly (make sure what you're getting is within the realm of what you're expecting) there won't be any negative consequences of leaving it so anything can POST to it.
Also, technically you can send POST data to any file on the web, it just depends on what the file does with it whether or not it means anything.
Also, what Mario Werner is talking about is CSRF tokens. That won't stop other things from posting to your site, it just adds a level of security that makes sure the request came from the right place. For a detailed explanation, you can read this: http://en.wikipedia.org/wiki/Cross-site_request_forgery
I have a PHP form, and I'm wondering how I should handle submission. I remember when learning Rails that the behavior was to have a special handler page for a form, which then redirected the user to a landing page, which would prevent the user from accidentally re-submitting data by hitting the back button and going back to the form submission page.
For my PHP form, to avoid such errors (and for secureness, however it might play in) is it also best to send the form data via post to a handling page, which they redirects the user? Or would it be ok to just handle the form data on the same page as the form? If I did the latter, is it possible for a user to accidentally resubmit data via hitting back/refresh/etc?
Post-Redirect-Get is the design pattern recommended for web-forms to prevent resubmission (and what you used in rails)
It doesn't really matter if you submit to the same page or a different one, it's the redirect which prevents the accidental resubmission. You can therefore choose whether to post to the same page or a separate page depending on your coding style and/or application semantics.
The same principles apply to PHP. Redirection can help against accidental form refreshing. However, you still should take whatever precautions are necessary to avoid problems from accidental refreshing (e.g., using single use tokens, validating the input, etc).
I use my own MVC style of framework that simply has the dispatcher look for form posts on every page view and calls the appropriate controller that can process the request (assuming the submit-only-once requirements were met). It then redirects the browser to the appropriate landing page.
You can post to the same page, of course, but I think it will lead to bad practices, such as mixing too much logic, html, and database access together.
There's a third way to go about this that I am particularly fond of. In an effort to separate logic from presentation, I like to include a PHP file with every HTML document that requires processing of some kind (such as displaying dynamic data, handling HTTP POST requests etc.). I generally store this file in a separate directory and name it "filename.page.php". Needless to say, this is nothing more than a coding convention and you may want to call it something else.
In a sense, this means you're handling the HTTP POST request in the same file (at least as far as your web server is concerned). You can redirect clients anyway, though, by using the HTTP Location header like so:
header("Location: file.php")
As a side note, I wouldn't depend upon HTTP POST for security; it is no harder to make arbitrary HTTP POST requests than HTTP GET requests.
I would like to ask this because if no quite sure that it secure.
I am planning on changing my page to ajax based registration. So my data will be inserted using jquery ajax post.
But if someone uses firebug and see where my post is being sent, they can use other form of firefox addons to post data on that url and can easily register without going to my page.
Although I can validate the request first where it is comming from though but that would be extra codes and work.
I will also add server validations for my form since someone can register without validation using the direct url that they will see on firebug.
I just wanted to know if there is already a standard procedures in applying ajax based data post.
But with ajax based select / fetch is cool and very useful.
Currently this is what I am planning on doing on my registration page.
validate that all request's must come from my registration page.
might use a transaction / request code
might use cookie
might use session
might use date time comparisson
if validation fails I should have a form validation on server side
to clean my the posted data before inserting to db
Never trust a UI.
Whether you do an Ajax post or a standard post, people can figure out what you are posting and create their own client. Even if you use https, the person controlling the browser can see what is posted and decipher the protocol.
You need to create your service so that it is not vulnerable to a user handcrafting a client.
If a user can use their browser to register on your site via Ajax, they can spoof the registration using some other programming language. There isn't anything you can do to make it so they can only register from your site via Ajax.
You can implement tricks to make it difficult for them to figure out, but you can't make it impossible. They can spoof the referrer, load other pages to get the required cookies/session variables, spoof Ajax request headers etc.
I am supposed to capture data from a form and send the data to a url on a different server.For eg:-I have a form on a page at the url http://www.form.com/register.php.
I capture all the data from this form and for some reason need this data to be processed on a page on another server at http://www.thereceivingpage.com/process.php.
As of now I am using headers to redirect with the parameters in the query string something like this:-Header(Location:http://www.thereceivingpage.com/process.php?name=alice&address=a1&address2=a2) but I need to send a larger amount of data which wont happen as GET request. Can anyone suggest a better way where in I can post data rather than the data in the query string ...thanks
Use cURL. If you have to redirect to the site, it gets a bit trickier but you can still do it. You can get the cookie and redirect information back from the site and then do a GET redirect using header.
Can you not update the action to simply post directly to that form? Otherwise, you might want to look into something like curl: http://ca.php.net/manual/en/function.curl-exec.php
You'll pretty much re-use the header redirect syntax with the parameters but instead you'll tell it to be a post.
redirect to a page on a different server and post parameters to it
thanks to internet standards, that's impossible.
if it's third-party site, let user to interact with it directly. do not interfere between them, it smells
If you want to develop secure applications then you should be aware that http://www.thereceivingpage.com/process.php is vulnerable to Cross-site Request Forgery (CSRF), meaning that anyone, from any site, can post form data to process.php.
process.php should be checking for a token (which www.thereceivingpage.com transmitted to the user as part of the form) and should be rejecting form submissions that don't contain the token to prevent submissions coming from anywhere but www.thereceivingpage.com and thus protecting your users from being manipulated into making requests they didn't want to.
In addition to your concern about the size of the GET requests you cause the client to make when redirecting, it's also not a good practice to turn POST requests into GET requests.
The best solution is to completely rethink the notion of delivering a form from one site to be submitted to a different site.
You can manually set headers and send request or you can use curl
see this
http://www.askapache.com/htaccess/sending-post-form-data-with-php-curl.html