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.
