Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future forms configuration #46

Open
I-Valchev opened this issue Jan 15, 2021 · 7 comments
Open

Future forms configuration #46

I-Valchev opened this issue Jan 15, 2021 · 7 comments
Labels
help wanted Extra attention is needed

Comments

@I-Valchev
Copy link
Member

I-Valchev commented Jan 15, 2021

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: [ [email protected], {FROM_FIELD} ]
              cc_recipients: ...
              bcc_recipients: ...
              attach: [ name of file fields to attach ]
        action:
            redirect: ...
            messages:
                success: ...
                error: ...
@I-Valchev I-Valchev added the help wanted Extra attention is needed label Jan 15, 2021
@bobdenotter
Copy link
Member

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

  • the fields configuration (and primarily the "options" and its "attr" flags) are clearly designed for people who write code, and are not user friendly for end-users who merely want to implement a form. To a large extent this is unavoidable, but we can document it better
  • We should be able to add attributes to the form itself. Like being able to influence the class/id of the form, without having to override the complex Symfony form templates.

@I-Valchev
Copy link
Member Author

Some other things to at least consider:

  • should there be a standardised way to select forms that belong to a page?
  • from builder?

@I-Valchev
Copy link
Member Author

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

@I-Valchev
Copy link
Member Author

  • It should be easier, or at the very least documented, how to override the HTML rendering of a specific field, of a field type, etc. Symfony allows that by extending templates and overriding blocks, but given the extra layer of abstraction that is bolt/forms, it is difficult.

@nestordedios
Copy link
Contributor

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

  • Easy way to override default Boltforms CSS.

@I-Valchev
Copy link
Member Author

  • Make the type: date, type: datetime and type: dateinterval easier to configure in terms of how it is rendered...
    Right now, to render a date with the standard datepicker, it looks like this:
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
  • More generally, see if we can provide "shortcuts" to common symfony/forms options (radio buttons, checkboxes, etc.) rather than asking people to set stuff like multiple: false etc..

@ghost
Copy link

ghost commented May 5, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants