Hi Ilya,
I'm glad to see your effort on this!

I'm not convinced that this deserves to be its own targeted thing rather 
than a more general request validator PSR. A more broad request validator 
PSR could handle more types of validators and validate the entirety of a 
request rather than just this one small aspect of request validation. For 
example, on a registration form submission I might want to validate the 
provided email, password, name, settings, etc. and I think by focusing on 
such a narrow swimlane for this might hinder future efforts to build the 
more broad PSR I'd prefer to see.

Can you speak to why this should be a standalone PSR and not a general 
request validator PSR?

Thanks,
Korvin

On Monday, June 30, 2025 at 8:42:13 AM UTC-7 LeTraceurSnork wrote:

> Good day, everyone!
> I would like to propose standardizing a new CaptchaInterface. It's main 
> purpose, as I see it, is to unify all Captchas external providers into one 
> simple interface that could be easily used when passed via DI. E.g.:
> ```php
> class SomeFormHandler
> {
>     function __construct(CaptchaInterface $captcha)
>     {
>         $this->captcha = $captcha;
>     }
>
>     function formSubmit($some_request)
>     {
>         $captcha_token = $some_request->get('captcha_token');
>         $verification = $this->captcha->verify($captcha_token);
>         if ($verification->isSuccess()) {
>             // captcha passed, do stuff
>         } else {
>             // captcha failed
>         }
>     }
> }
> ```
>
> The reason why I'm doing this, in a nutshell - to speed up potential 
> switches from one vendor to another, avoiding potential vendor-lock and 
> unifying SDK usage in a future
> And while I'm saying "potential", please, don't think I'm paranoid :) We 
> actually faced this problem recently and now had to switch captcha vendor 
> from Google ReCaptcha to something else. And sadly enough, that something 
> else doesn't have its own SDK, so, now unofficial will appear as mushrooms 
> after a rain - and they better be unified with one another due to the 
> reasons described above.
>
> Well, more to that (and a lot of comments with interested in that 
> developers) you can find in a PR: 
> https://github.com/php-fig/fig-standards/pull/1330
>
> --
> Best regards,
> Saligzhanov Ilya
>

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/php-fig/9a3b681e-c046-4391-999d-b6d5a39713c1n%40googlegroups.com.
  • PSR proposal:... LeTraceurSnork
    • Re: PSR ... Korvin Szanto
    • Re: PSR ... 'Andreas Heigl' via PHP Framework Interoperability Group
    • Re: PSR ... Jaap van Otterdijk
      • Re: ... LeTraceurSnork
        • ... Jaap van Otterdijk
          • ... LeTraceurSnork
          • ... 'Andreas Heigl' via PHP Framework Interoperability Group
            • ... LeTraceurSnork
              • ... 'Alexander Makarov' via PHP Framework Interoperability Group
                • ... LeTraceurSnork

Reply via email to