I support the effort and will join the WG. There are many CAPTHCAs in the wild. They're mostly evil, but we have to deal with these and having a common interface that works will make our lives easier.
On Wednesday, July 2, 2025 at 2:27:03 PM UTC+3 LeTraceurSnork wrote: > @AndreasHeigl, I agree that Captchas itself may be an antipattern (which > is disputable, but anyway), but I guess thatyou mean Captchas in a narrow > sense - those Google Captchas with disappearing traffic lights and stuff > (or even older ones with curly texts) - yeah, they probably are. But in > terms of this PSR, proposal, interface I implied Captcha in a broad sense - > ANY kind of check that returns stringified $token that can be verified > afterwards. It doesn't needs to be traffic lights, it doesn't needs to even > be visible - there are bunch of invisible Captchas nowadays - ReCaptcha V3, > for example. Another example - SmartCaptcha, it's even better, it's > invisible at first, but if you have "bad score" - only then it appears and > asks you for... curly texts, traffic lights, etc. xD > Proposed interface doesn't tell you where from to get that token - you may > randomly generate it if you want, take it from another API, hire a bouncer > that will tel "you pass, you don't" - the origins of the token is a > blackbox, and the scenario begins only after token was already passed > I can easily see how invisible Captchas implements this interface > (actually, one already do - you can see my example if you wish > https://github.com/LeTraceurSnork/unofficial-captcha-sdk/pull/1 - still a > PR, unfortunately, but soon-to-be-merged) > I can easily see how non-external Captchas pass this (those ones with > 4-digits code in colors, or the ones with formulas like "calculate 25+12") > I can even see how no-captchas solutions may pass this (User-Agents, IPs, > etc. - generates a token, stash it to session and verify it on backend) > > So, while I partially may agree with your point, it has no direct > connection to PSR, cause Captcha isn't always ... Captcha? xD Sometimes > it's different kind of tests > > вторник, 1 июля 2025 г. в 11:02:42 UTC+5, Andreas Heigl: > >> Hey all. >> >> Am 30.06.25 um 23:31 schrieb Jaap van Otterdijk: >> > 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. >> >> I wholeheartedly agree with Japp here for several reasons: >> >> Captchas are - despite their wide usage - an antipattern. The fact that >> they are used on a lot of platforms does not mean that it is a good >> idea. A lot of people are using timestamps or convert dates to UTC when >> there are better options available. Just because people do it does not >> mean it is the right thing to do. >> >> Providing an interface from the FIG explicitly for Captcha-Usage will >> make it look like the FIG supports this anti-pattern. I would rather not >> see that. >> >> On the other side though a Captcha is something that is included in a >> form. It is one form field. If you don't use forms, you don't need >> captchas. >> >> And what indeed is missing - and I just stumbled upon this in another >> project I am working on - is a set of interfaces that allow be to easily >> build, display and validate a form. SOmething that allows me to add >> form-fields from different sources to a form "object" and then easily >> render that and in the next step validate it. >> >> Something like $form->add(new TextField('name', 'value', 'default', ...)) >> >> And once there is such a "FormBuilder" interface set that allows adding >> different fields from different sources (as they all share the same >> interfaces) it should be no issue at all anymore to call then something >> like $form->add(new Captcha('name', 'value', 'id-key', 'whatever else')); >> >> Which then allows easily exchangeable Form fields. So then the only >> thing missing is different implementations of the interface for >> different Captchas. Switching them out should be a breeze >> >> This way it is easy to use Captchas if you need to (You still should not >> and you should make your managers understand why not!) but there is no >> need for a specific captcha-related interface. >> >> My 0.02 >> >> Cheers >> >> Andreas >> -- >> ,,, >> (o o) >> +---------------------------------------------------------ooO-(_)-Ooo-+ >> | Andreas Heigl | >> | mailto:[email protected] N 50°22'59.5" E 08°23'58" | >> | https://andreas.heigl.org | >> +---------------------------------------------------------------------+ >> | https://hei.gl/appointmentwithandreas | >> +---------------------------------------------------------------------+ >> | GPG-Key: https://hei.gl/keyandreasheiglorg | >> +---------------------------------------------------------------------+ >> >> -- 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/24f73bf2-73fd-484a-b754-7eac8de2ed28n%40googlegroups.com.
