bolt / forms

MIT License
21 stars 27 forks source link

Future forms configuration #46

Open I-Valchev opened 3 years ago

I-Valchev commented 3 years ago

Hi all

Here's a suggested configuration for a future major release of bolt/forms. Please provide any feedback that you may have!

## This is default, all forms inherit from here.
default:
    csrf: true
    honeypot: true
    spam-action: mark-as-spam
    template: '@boltforms/form.html.twig'
    layout: 'form_div_layout.html.twig'
    captcha:
        repatcha: ...
        hcaptcha: ...

contact:
    csrf: false # here you can override any of the default config
    attr: ?? # Add attributes to form itself?
    content:
        step: 1
        fields: ... # Same as current form
    on_submit:
        save:
            contenttype:
                name: ..
                field_map: ...
            table:
                name: ...
                field_map: ...
        email: # the email is a list, allowing you to send as many emails to as many recipients as you like
            - subject_template: ...
              body_template: ...
              recipients: [ foo@example.org, {FROM_FIELD} ]
              cc_recipients: ...
              bcc_recipients: ...
              attach: [ name of file fields to attach ]
        action:
            redirect: ...
            messages:
                success: ...
                error: ...
bobdenotter commented 3 years ago

Some other pitfalls we'll need to avoid if we're going to refactor this and introduce breaking changes:

I-Valchev commented 3 years ago

Some other things to at least consider:

I-Valchev commented 3 years ago

Also: https://wpforms.com/features/

I-Valchev commented 3 years ago
nestordedios commented 3 years ago

@I-Valchev as we discussed, it might be good to have it in the list as well:

I-Valchev commented 3 years ago
date_of_birth:
    type: date
    options:
        widget: single_text

Would be much better to have something that is human comprehendable, for example:

date_of_birth:
    type: date
    variant: datepicker
ghost commented 2 years ago

Id like a speedlimit key for forms as an antispam countermeasure. Most spam messages are sent within 100ms. I'd like to set individual limits for each form for the minimal interval between page request and form submission. speed violations should result in a block.

On top of this i would prefer a more granular spam protection rather than none/block/mark-as-spam as a global result for all . For example we can be pretty sure, a filled honeypot must be a robot and should be blocked. broken csrf tokens are also garbage and should be blocked. a v2 recaptcha produces a boolean which should be blocked a v3 recaptcha produces a float which should likely have a minimal threshold resulting in a block (ie: 0.3) and also a minimal value resulting in mark-as-spam threshold (ie:<0.7)

lumping csrf, honeypots together with the v3captcha is far too crude in my humble opinion.

on a less related sidenote spam protection may warrant its own key in the config:


spamfilter:
    csrf: block #block/mark/none/false
    honeypot: block #block/mark/none/false
    speedlimit:
        time: 100 #minimal required wait in milliseconds between page request and form submission
        action: block #block/mark/none/false
    captcha:
        privatekey: #YOUR_PRIVATE_KEY
        sitekey: #YOUR_SITE_KEY
        hcaptcha:  block #block/mark/none/false
        recaptcha_v2:  block #block/mark/none/false
        recaptcha_v3:
              blockbelow: .3 #float between 0-1 inclusive
              markbelow: .7 #float between 0-1 inclusive