Feature: passive mode in configuration not working about antispam-bundle

[curry684]

Sorry yes the passive mode was just implemented on validators today haha. Passive mode on forms is still to come, but kinda useless until the quarantine also works (next up) and the logging (after that). All require events (added today 😉 ).

I actually only tagged 0.1 today so our internal projects I'm using for testing can use stable packages. However that DOES mean that I'm actively doing release management, and releases should be stable and reliable. Just not feature complete yet.

[kbond]

Sorry, didn't realize this bundle was still in heavy development.

I see you just added the passive mode earlier today and is unreleased but even using dev, making it true in my configuration profile still creates validation errors.

[curry684]

So yes it's a feature, not a bug haha.

[kbond]

Looks like configuring passive in the profile's config works but not the global config yet?

[curry684]

Correct, already fixed locally.

[curry684]

It may be downright confusing right now though. The profiles have their own stealth and passive settings, which override the global config. In practice the global settings are only used by validators and form types outside of profile context. It may cause confusion that the global settings aren't doing anything if the profiles have defaults that override them (and at least for stealth for good reason).

Thinking on how to make that clearer and/or make more intuitive.

[kbond]

Ok, so the solution for the recipe is to enable passive on the default profile, correct?

In practice the global settings are only used by validators and form types outside of profile context.

Ahh, ok, yeah, I didn't realize this was the intention.

[curry684]

Ok, so the solution for the recipe is to enable passive on the default profile, correct?

Yes that would be the quick fix.

[curry684]

I think for Stealth the current situation is fine (global default false, profile default true).

However for Passive I think it makes more sense that the profiles default to null, meaning fall back to global. In that case the current recipe would still work, and that's intuitive methinks.

[kbond]

Let's first figure out the purpose of the global options:

1. passive: my intuition told me this was a global override (for profiles/validators/types). The use case would be to enable globally in production to perhaps debug issues or to disable in tests.
2. stealth: this one I have a hard time understanding the purpose. I can't think of why you'd want to configure this one globally - can you describe the use case? I wonder if this global option is required?

One idea would be to remove these two global options and replace with enabled (defaults to true). When false, all antispam configuration is ignored. This would be the easiest to reason about but... you'd lose logging/quarantining.

[curry684]

On the passive option we agree then, and my proposal above to make it overridable on the profile level is correct.

For the stealth option it is important to keep in mind that this bundle provides a ton of form types and validators (and will have more in the future), and the option to organize them into profiles for easy mass application. The profiles are expected to fit the 95+% use case, but in some cases you may want to customize or have dynamic settings. You can, and some people will, use the validators in any entity, in APIs (no forms, so no profiles!) or on plain old objects. You can, and some people will, use the form types manually, for example when the honeypot or submit timer settings are actually made configurable, or forms are dynamically created.

The global stealth option applies to all bundle components when used in the ~1% use case, outside a profile. It's merely a shorthand for setting it manually on every single validator and form type.

[kbond]

Thanks for the explanation, I understand. So what about the following for global config:

1. passive, keep as now
2. stealth, match passive behaviour - I feel it's confusing if the logic is different so global=true, profile=null
3. enabled, add as a global option - this would be what we disable when@test in the recipe

[curry684]

It should make more sense now: https://omines.github.io/antispam-bundle/features/