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.
