Solved! Go to Solution.
Here is the product team's official stance on this:
For pre-fill to work on embedded forms, it requires a publicly accessible API that retrieves lead information, which can include personally identifiable information such as email addresses, mailing addresses, names, and phone numbers. For us to make enable pre-fill on embedded forms in a responsible manner, we need to make certain that the API is created in such a way that it’s acceptably protected from brute force attacks that could allow an attacker to retrieve information about all leads by guessing Marketo cookie values, as well as making certain that the API doesn’t expose leads to XSS (cross-site script) attacks that could be used by an attacker to steal a lead’s info when they visit the attacker’s site. These issues doesn't exist when the form is on a Marketo landing page because we process the content of the page on our servers and there is no API exposed publicly.
This is 100% on our roadmap and we know how much customers would like this...it just requires a very thorough review by our internal security team. I plan to work on this next year.
Any updates on whether embedded form pre-fill works?
There's no official support. Unofficially, it is possible using a crafty method.
Are you referring to this?: http://developers.marketo.com/blog/external-page-prefill/
Well, no. Because I would never expose my REST API call limit to the public.
Hey Sanford Whiteman - sorry to bug you, but we're planning on possibly moving forward with the instructions in that MKTO Developer article I added up there. What would you do differently if taking that approach? You can message me as well - thanks.
You can't use the method from that post without creating a DoS attack vector against your instance. Using individual REST API calls in response to unmetered end-user actions can be disastrous.
DM me and I'll work offline with you to implement the safer, scalable approach.
Hi Sanford,
Thanks for providing the insight. We launched a brand new site and moved away from the iframe method to the embedding method. I will send you a message.
Hi Sanford,
Would it be possible to have your details (cant see how to DM on the community) to discuss this approach?
Regards
Josh Soffe
hmm, so that document is no good? do you have a work around for what you mentioned?
Here is the product team's official stance on this:
For pre-fill to work on embedded forms, it requires a publicly accessible API that retrieves lead information, which can include personally identifiable information such as email addresses, mailing addresses, names, and phone numbers. For us to make enable pre-fill on embedded forms in a responsible manner, we need to make certain that the API is created in such a way that it’s acceptably protected from brute force attacks that could allow an attacker to retrieve information about all leads by guessing Marketo cookie values, as well as making certain that the API doesn’t expose leads to XSS (cross-site script) attacks that could be used by an attacker to steal a lead’s info when they visit the attacker’s site. These issues doesn't exist when the form is on a Marketo landing page because we process the content of the page on our servers and there is no API exposed publicly.
This is 100% on our roadmap and we know how much customers would like this...it just requires a very thorough review by our internal security team. I plan to work on this next year.
Justin Cooperman - Back in 2014 you said "This is 100% on our roadmap and we know how much customers would like this...it just requires a very thorough review by our internal security team. I plan to work on this next year." Did anything change in the intervening time? I have a client using embedded forms and on some of them prefill works but on others it doesn't. I suspect a developer implemented a workaround for them on the pages where it works and that nothing has changed for the "out of the box" embedded forms. Would you please confirm either way?
Thank you!
Denise
Over the last year, our team's focus around munchkin and forms experiences has been to ensure GDPR compliance and "privacy by design" of the existing functionality. We've made a few security improvements and we do still have a few more we're making. Once we get that all wrapped up, there's a PM working on a few forms enhancements like this one. The API workaround Sanford published is a nice approach for the time being. But, make sure whatever you deploy aligns with your team's internal GDPR stance as well.
Looking forward!
Did I publish it yet?
It's actually going open-source today:
(Doesn't use the API, for sure.)
Sweet, makes my life easier for the time being!!! Give me quick high-level, is it passing data to parent window object?
Justin
Yep!
Hi Sanford, could you please send me the link to subscribe to your blog digests?
[EDIT]
Nvm found it!
Sure: https://blog.teknkl.com
Thank you, Sandy and Justin! I second Greg's request for a link!
I think you guys both follow so I'm trying to get it out for the 6pm email digest today. If not, then it'll be up tonight and in the email tomorrow.