Form that Prevents Non-Clients from Entering | Community
Skip to main content
T
Tom_Kerlin2
Level 7
April 8, 2016
Solved

Form that Prevents Non-Clients from Entering

  • April 8, 2016
  • 2 replies
  • 2349 views

Hi,

Has anybody tried to build out a form that allows only certain users to pass through? Is is possible to build out a form that will keep non-clients from entering?

Is there a login field I can set up for email address and password?

I appreciate your feedback.

Thanks,

Tom

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman

Robb's suggestion of segmentations is great for this if the leads are already in Marketo (as opposed to leads that match a client domain but aren't themselves in the db yet). It won't stop users from posting the form, but it will ensure that they see the correct content.  However, note that they may not see the content immediately (that's another technical story).

There are some other approaches, but their acceptability will depend on your definition of "prevent." 

See, Marketo doesn't do server-side form validation at the point of submission (you can check posted values in a Smart List and discard the lead, but you can't stop the form from submitting as far as the browser knows). And client-side form validation in the browser can always be circumvented by mildly technical users.

But if your goal is just casual validation -- you're not trying to stop people who'd make a malicious attempt to get around validation -- then you can check the Email against any list you want. It's like the "stop people from entering freemail addresses" concept.  Easy for a person with minor technical skills to get around, but if you're trying to dissuade leads so anyone doing anything dirty knows they're being dirty, it'll work fine. You can store the list as a JS variable right on the page (though that's really easy for someone to see with view-source) or in a separate file (harder to "accidentally" see).  Or you could store hashes in a separate file, though the complexity is probably not worth it given that it can still be circumvented.

Re: passwords, Marketo isn't equipped to create extranets or authenticated asset libraries.  If you don't care about real security but just "suggested security," you're free to put a random... let's call it, "keycode" as opposed to "password"... in a custom field. Comparing a posted password to the stored password, though, requires a webhook.  This isn't a road worth going down IMO.

2 replies

Robb_Barrett
Robb_Barrett
Level 10
April 8, 2016

You can create a field for those attributes, along with a field that checks what kind of user they are.

Also, you can create segmentations and assign leads to segments and display different content on the page for each segment.

Robb Barrett
    SanfordWhiteman
    SanfordWhitemanAccepted solution
    Level 10
    April 8, 2016

    Robb's suggestion of segmentations is great for this if the leads are already in Marketo (as opposed to leads that match a client domain but aren't themselves in the db yet). It won't stop users from posting the form, but it will ensure that they see the correct content.  However, note that they may not see the content immediately (that's another technical story).

    There are some other approaches, but their acceptability will depend on your definition of "prevent." 

    See, Marketo doesn't do server-side form validation at the point of submission (you can check posted values in a Smart List and discard the lead, but you can't stop the form from submitting as far as the browser knows). And client-side form validation in the browser can always be circumvented by mildly technical users.

    But if your goal is just casual validation -- you're not trying to stop people who'd make a malicious attempt to get around validation -- then you can check the Email against any list you want. It's like the "stop people from entering freemail addresses" concept.  Easy for a person with minor technical skills to get around, but if you're trying to dissuade leads so anyone doing anything dirty knows they're being dirty, it'll work fine. You can store the list as a JS variable right on the page (though that's really easy for someone to see with view-source) or in a separate file (harder to "accidentally" see).  Or you could store hashes in a separate file, though the complexity is probably not worth it given that it can still be circumvented.

    Re: passwords, Marketo isn't equipped to create extranets or authenticated asset libraries.  If you don't care about real security but just "suggested security," you're free to put a random... let's call it, "keycode" as opposed to "password"... in a custom field. Comparing a posted password to the stored password, though, requires a webhook.  This isn't a road worth going down IMO.

    T
    Tom_Kerlin2Author
    Level 7
    January 9, 2017

    Hi Sanford,

    Can you post an example JS variable (custom code for password validation) with list of field values/codes that would be considered acceptable? I'd like to create a snippet and test on a landing page.

    Thanks,

    Tom

    Tom Kerlin
    SanfordWhiteman
    SanfordWhiteman
    Level 10
    January 9, 2017

    Hi Tom,

    Pasting my response from another thread that has too much chaff/misinfo:

    If you upload the raw Freemail-Disposable file to your Marketo instance you can seamlessly validate against it like this:cdpn.figureone.com/figureone/debug/8e33a954137850d2d374aaccb0d30403 (code)

    The linked Pen above is an example of how you can keep your list of bad domains in a separate file (far easier to update than bundling that list with the page or form).

    Although the blacklist of bad domains is probably way longer than your whitelist, you can use exactly the same approach. To check for good domains, just switch the validation condition.

        if (!goodmaillRE.test(form.getValues().Email)) {
          form.submittable(false);
          form.showErrorMessage(goodmailError,emailJQ);
        }

    etc.

    Terms & ConditionsAccessibility statement

    Loading footer...