Thanks again for taking the time to give us an answer. It just underlines my statement that your efforts to get this done are huge.
I was thinking again about your answer. And while reading I realized you have a point about the struggle we would have to come with an interface for request validation. It's a hairy topic. Because everyone is doing this in their own way. But that's exactly the point of a standard. It's not just the matter of getting things done. It's about the value it provides. The interface for a captcha seems to me a very small work field. While you could argue that that's a good point. I think interfaces that have a bigger focus are better in place. Not that the interface itself should be large, but the way it can be used should be brought. At least in a standard lib. Or it should focus on a very common problem. The psr standards all focus on very common patterns in a web application. Everyone needs logging, service containers can be found everywhere, and there is literally no php application out there that doesn't do request response. That's why those deserve a psr. That's also why I think validation would be a very good candidate. Because validation is everywhere. . For captcha this is a different story. While there are many captcha providers, not all applications use captcha. It's not a common pattern. It's a solution for a specific problem. So the amount of applications actually using it will be very limited. If the would even exist in the future. I think more and more companies are actually looking for a better way to validate their users are human. I really tried to see the value. But I simply don't get it for this particular psr. Op ma 30 jun 2025 21:55 schreef LeTraceurSnork <[email protected]>: > Good night, gentlemen! > Well, allow me to defend my point then :-) > *@KorvinSzanto* actually, you have a very strong point now, I'm even > starting to think that this PSR actually is unneeded, but! There is always > a but - even tho it was also in my mind to propose Validators PSR (as I > mentioned in Discord earlier), somehow I think that if Captcha gathered so > many opinions, so many disagreements and strugglings, while there is only > one, rougly speaking, global implementation (ReCapctchaV3) that almost > everyone use and get used to its interface, I already see how many > disagreements will be on Validator PSR and how long will it take to get him > to Draft at least. While Captcha is already in business. And yes, now I > actually see, that it fully covered by nonexistent (yet) ValidatorInterface > with its only two semantical methods - say, `::simpleValidate($data): bool` > and `::extendedValidate($data): ValidatorResponse` > And now to the point, where you and *@JaapVanOtterdijk* intersects: Yes, > we can (probably) realise Captcha verifier via PSR-15 with > PSR-7+PSR-18++++smth else, but (again) - as sol*I*d insists - we shall > not. We shall not add Captcha verifier class methods it doesn't need - and > I, as a user, and also as a developer of an internal-usage captcha SDK, > definitely don't need `::getHeader()`, `::getHeaderLine()`, `::withBody()`, > etc, etc. - from PSR-7 and I also find PSR-15 just too redundant for that > matter. > > *All I want as a captcha* user (developer-user) - is: > 1. Grab my user's token > 2. Pass it to something along with `secret_key` > 3. That something must tell me `true`-`false` where `true` is "my user > passed captcham he is not a bot" > That's all, I don't want to validate their values, generate requests on > requests, responses on something, meeeh. Just take my string and say > yes-or-no - simple interface as it is. And that simple interface is now > absence. > So, the main question is - do we want that simple interface? I believe we > do > And if you answer "yes, but we can present it in Validator PSR" - I agree > with you. But until then we can present it via Captcha PSR and then, if > needed, turn it into Deprecated/Abandoned > > *Summary*: I believe that interfaces should be semantical. And nothing > more semantical for captcha validation then specific Captcha validator > interface > > @AndreasHeigl well, we can't just ignore it - captcha is just the matter > of fact for now. Good, bad, evil - it just is, it presents on the web, > users pass it on daily basis, and developers are forced to verify it. And > without proper interfaces it hurts :-( > > понедельник, 30 июня 2025 г. в 23:42:00 UTC+5, Jaap van Otterdijk: > > 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 <[email protected]>: > > 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 [email protected]. > 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 [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/php-fig/b6130465-ff8c-4d5c-aca1-83371622865fn%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/b6130465-ff8c-4d5c-aca1-83371622865fn%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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/php-fig/CABS-R8-5eG62zSHdbEYjyXxtHLRfGiDdoaNRGTF42BR_Fe9Ang%40mail.gmail.com.
