Hi,
I have been following the captcha pr for a while. And I still have my
doubts about the approach. If we look at the example code given here it
could have been wrapped in a psr-15 middleware implementation. As you need
the request, get some information out of it, and either fail or continue.
I do understand your point about not having a vendor lock in your code
base. So from that point of view I get it. However I'm not sure we need a
psr for this particular topic.
I think others also suggested to make this a broader psr that covers
validation. Which would make sense if we could standardize the input and
output and the way errors are reported. But as the whole validation chain
has a lot of opinions, I think you would have a very hard time to
standardize that.
Neverless, I would like to praise you for all the work you did up til this
far. I can see you are really willing and listening to others. I will keep
following your progress.
Op ma 30 jun 2025 17:42 schreef LeTraceurSnork <letraceursn...@gmail.com>:
> 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/4e708808-cfd6-428d-85c0-16e3cad763e8n%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/4e708808-cfd6-428d-85c0-16e3cad763e8n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CABS-R8_cyKggCcE%2Bt1YHVM%2B9DHxPGysPvJi0jP%3Dd5FG%2Bxk9ttg%40mail.gmail.com.
