I'm using this tutorial http://developers.marketo.com/blog/server-side-form-post/ to post form data back to marketo from my site.
I am getting a issue relating to the Ajax response
XMLHttpRequest cannot load https://app-lon.marketo.com/index.php/leadCapture/save. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.mysite.com' is therefore not allowed access.
The above error prevents the Ajax success function from triggering.
Is there a way I can either circumvent this issue?
If the marketo sub-domain is only for my marketo account, would it be feasible to request that marketo add in the correct headers on the server side file for my domain(s)?
Thanks
Surely that's not a server-side form post. It's a client-side (browser-side) post. Servers don't care about CORS.
You don't to do anything like this. You can post using the Forms 2.0 API, which is the recommended method. More info here and in other Commty posts.
We are rolling out a temporary solution for several site on several hosting platforms. Part of the brief is that switch from current form and autoresponder systems to marketo be seamless from an interaction and front end perspective, whilst talking to our existing systems.
I have built a js form builder that takes the marketo form id to build out the form using any of our site existing mark up methods and styles.
All the form builder needs to know is the marketo form id and is gets the json output of the form.
The script then itterates through each form item in the array to output the form as built in marketo, with a few minor items left out.
As i said above I'm getting issues where the ajax response from the marketo sub domain returns an error so our ajax success does not fire.
The ajax success is supposed to hide/show the form/thank you message and send additional analytics events to google.
There are cases where the content of the form thank you message is dynamic as it's generated based on a url query, for example the url query might be a document file name, so the form thank you contains the link for the document download.
This affects all browsers, with ie 8 being the worst affected as the ajax error even prevents the data from being sent to our leads database
I wondered if we could arrange with marketo to set the headers on the marketo subdomain to allow access from all or a list of sites. something like this in a htaccess file.
Header add Access-Control-Allow-Origin "*"
We have two alternate solutions.
A direct curl function which works in all browsers but has no authentication method, we run a for each loop to post all field generated as part of the form build.
Or a rest method which submits the lead, but we cannot see how we would tell marketo that it can from which formid, also the rest api field names are different from the names provided from the json array.
This affects all browsers, with ie 8 being the worst affected as the ajax error even prevents the data from being sent to our leads database
Of course! This is the very definition of why using a prebuilt, tested, cross-browser forms API is necessary.
The Forms 2.0 API uses a cross-domain IFRAME shim that solves all of these problems. To repeat: there is no need to show the underlying Marketo form to the user in order to use the Forms 2.0 API for form submission.
You could build your own solution using XDFrame, et al., but that's just busywork when there's literally an API included with the product that already does all that, and does it well.
I wondered if we could arrange with marketo to set the headers on the marketo subdomain to allow access from all or a list of sites. something like this in a htaccess file.
Header add Access-Control-Allow-Origin "*"
I hope not. You're talking about dramatically changing the security model for all tenants, even though there's an API that works with the existing security model.
A direct curl function which works in all browsers but has no authentication method, we run a for each loop to post all field generated as part of the form build.
I wouldn't say it "work[s] in all browsers" because it doesn't work in the browser at all. That's your server-side form post. It also is throttled to one form post every 2 seconds, which is suboptimal, but not as bad as the below.
Or a rest method which submits the lead, but we cannot see how we would tell marketo that it can from which formid, also the rest api field names are different from the names provided from the json array.
Never, ever do this. Using a REST API call in response to individual end-user activities creates a major DoS vulnerability against your instance -- not only this integration but all your integrations. Use API calls only for bulk actions (and still use proper throttling and queuing).
Hi Sanford,
Thanks for the feedback, I was not aware of the curl throttling or the rest api issues.
Are you able to send me any documentation relating to the curl throttling or the rest api issues?
Neither was I aware that the request to set allow access headers to a wild card or a specific domain would affect all tenants, not just our marketo sub domain. I assumed a marketo sub-domain was unique to our account, so I was intending to talk to marketo support to ascertain if the request was both possible and acceptable with marketo and their security policies.
Discussing the ajax error and the access control issue with my team, we are testing a server side post handler file for forms on both php and .net platforms.
Reading the blog post you highlighted above, I'm not sure that's going to solve the specific problems we face for rolling out marketo integration across our sites.
These are the challenges we are facing when trying to integrate our sites with marketo:
I've put together a work in progress demo of how the plugin works.
Some form items have not been declared yet in the js function.
The form action process file has been commented out for demo purposes, and in production each site will have its own process file.
There are a set of JavaScript options declared on the HTML page, the only required option is the marketo form ID, the JavaScript function takes this ID and calls the required json file for the form.
As I said above this is a temporary solution as part of bigger project to unify processes and third party dependencies across all sites with in our business with in a certain time frame.
DEMO: http://jsfiddle.net/onebitrocket/2j4r2k7k/
I hope the demo shows in a little more clarity how we are intending to approach marketo form integration across our sites
Thanks for the feedback, I was not aware of the curl throttling or the rest api issues.
Are you able to send me any documentation relating to the curl throttling or the rest api issues?
It's not cURL throttling. Any form post, regardless of language/app, gets throttled to one post every 2 seconds per source IP. Obviously this places a greater burden on server-side posts, which are attempting to process hits from many clients. That's why client-side posts are by far the better practice.
The REST API limits are well doc'd on developer.marketo.com.
I hope the demo shows in a little more clarity how we are intending to approach marketo form integration across our sites
Yes (and sort of looking away from the form assembly using string concatenation -- definitely not how I would do it!) I see nothing that stops you from using the Forms 2.0 API for submission.
You happen to be using a jQuery Form Plugin. That plugin has an event handler, beforeSubmit, that passes to a custom callback all the form data that has been gathered and validated by the plugin. That's where you can call the Marketo Forms 2.0 API form::submit using the same data.
This is all you need:
Updated Fiddle here.
Still not really feeling your string-based form builder, though. DOM methods are a lot easier to use and easier to read. In fact, if you simply let the real form render hidden, you could pluck out the DOM elements you want and wouldn't have to create them at all.
HI Sanford,
Would you mind removing the fiddle, or making it private
We've been getting leads coming through from your jsfiddle account.
Thanks
Sure, done.
Thanks, appreciate it.