SOLVED

Re: Forms 2.0 : embedded forms do not prefill ?

Go to solution
Anonymous
Not applicable
I've just tried to implement new forms on my domain. Works great. Thus I could switch all my forms and stop doing the "iframe" workarounds.
One major issue I don't succeed in fixing : pre-fill does not seem to work / fields do not populate with my lead details.

Anyone can help with this ?

Thanks all. Love you.
Tags (1)
1 ACCEPTED SOLUTION
Justin_Cooperm2
Level 10

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.

View solution in original post

64 REPLIES 64
Mikes_Jones
Level 8

Any updates on whether embedded form pre-fill works?

SanfordWhiteman
Level 10 - Community Moderator

There's no official support. Unofficially, it is possible using a crafty method.

Mikes_Jones
Level 8
SanfordWhiteman
Level 10 - Community Moderator

Well, no.  Because I would never expose my REST API call limit to the public.

Mikes_Jones
Level 8

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.

SanfordWhiteman
Level 10 - Community Moderator

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.

Ayan_Talukder
Level 5

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.

Anonymous
Not applicable

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

Mikes_Jones
Level 8

hmm, so that document is no good? do you have a work around for what you mentioned?

Justin_Cooperm2
Level 10

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.

Anonymous
Not applicable

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

Justin_Cooperm2
Level 10

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.

Grégoire_Miche2
Level 10

Looking forward!

SanfordWhiteman
Level 10 - Community Moderator

Did I publish it yet?

It's actually going open-source today:

pastedImage_1.png

(Doesn't use the API, for sure.)

Justin_Cooperm2
Level 10

Sweet, makes my life easier for the time being!!! Give me quick high-level, is it passing data to parent window object?

Justin

SanfordWhiteman
Level 10 - Community Moderator

Yep!

Ayan_Talukder
Level 5

Hi Sanford, could you please send me the link to subscribe to your blog digests?

[EDIT]

Nvm found it!

https://blog.teknkl.com/

SanfordWhiteman
Level 10 - Community Moderator
Anonymous
Not applicable

Thank you, Sandy and Justin! I second Greg's request for a link!

SanfordWhiteman
Level 10 - Community Moderator

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.