Currently I'm having recaptcha fire an event when its done, and just set

hx-trigger

to listen for it. But yeah, dunno, might be a better way.

Last time I worked w/ a recaptcha it set a hidden input value to be verified server side, so I included it in the form submission for login

Oh yeah that was v2, v3 integrates some fancy javascript anti-fraud stuff, so has to be part client side.

Am I just behind the times? People using something other than google recaptcha? aha

gotta protect dem forms.

hello guys, I need some help 😢 I am working on a project where I have a form that send a hx-get request using some input elements. These elements/attributes are used for data filtering. One of the input element is a "datetimepicker", and I would like to trigger the htmx request only when the "datetimepicker" is closed, not while the user still selecting the date & time.

just a wild guess but... set

hx-trigger

to the event you actually want? 😂

do you? really? input validation (client and server side both: suspenders and belt before committing to your data store) should mitigate garbage/malicious submissions. DDOS protection should be handled at a different layer. otherwise, you're just giving free labor to Google. captchas were tres cool a decade+ ago but now they're just theater.

Hi folks! HTMX seems like a wonderful library and I've been exploring using it for a new project, but have run into a problem. I'd appreciate any insights, as I love the idea of the library and would very much like to continue using it. The basic setup is that I have a login form being submitted with

hx-post

, and

hx-target

targets a status div inside the form. When a user logs in but no user account exists, the returned HTML contains a second submit button which allows the user to sign up instead. This is valid HTML and perfectly safe (https://stackoverflow.com/questions/547821/two-submit-buttons-in-one-form), but clicking on the new button prints

htmx:targetError

error to the console. The full stack trace is below. One possibility is that hooking up the new button properly involves re-initializing not just the new content but the entire form, and perhaps this runs into an edge case inside of HTMX. This is just a guess and could very well be wrong; any thoughts would be very much appreciated!

htmx:targetError
logError @ htmx.js:1785
triggerEvent @ htmx.js:1802
triggerErrorEvent @ htmx.js:1757
issueAjaxRequest @ htmx.js:2500
eventListener @ htmx.js:1300

I want to believe but Mmm have you ever hosted a public facing system where users can post content? Its not just about DDOS... v3 recaptcha is literally just a thing in the corner that judges human-ness based on mouse movement and stuff. No pictures except in extreme cases where the user is suspected a bot.

Man, v3 must really think I am mechanical. And yes, I've been working on public web apps for decades now. Validation also includes spam and prohibited content filtering.

How do you defend against: Dozens of IPs posting humanlike text with embedded spam links?

that's what a WAF is for. also, i'd ask why are you allowing links at all in the input?

Use cases: user profile homepage. plaintext url. Any sort of image upload or image link.

WAF.. so you're gonna block all IP from a specific country? A lot of spam bots from Germany, USA. Not just India.

Debugging

contemporary WAFs don't jst block at the IP layer. they sit behind TLS termination and can inspect the HTTP requests coming into your application for known vulnerabilities. WAFs like the one at AWS can also look at lists of TOR output nodes, known bad IP blocks, etc. they're a blunt instrument for sure, but when you need to disallow bulk traffic that meets known bad actor patterns, they work. bad actors generally make their dosh off of bulk action (i mean, is the return on poisoning any single random form that lucrative? probably not. 1(0)000s of them? maybe/probably). security has to be multi-layered and appropriate to the situation.

Interesting. Yeah certainly an option. Personally not interested in deploying or paying for that but thanks for the perspective

yeah. there are no silver bullets, as they say. you gotta do what's feasible for your audience and budget. security is a process more than a product and a lot of is is kinda jank. i had to answer a 100-question infosec survey from one of my customers this morning that was 100% CYA garbage that makes nothing more secure other than some administrator's OKR.

just discovered HTMX and oh boy is it an answer to my prayers of how the javascript framework centric paradigm have overengineered the present web development world into a complete mess.. In my last two jobs I inherited react and angular apps and for a long time I had to get things done "in spite of" the tool, not with the help of. Taking a long time to do simple things because the tooling is overly complex and obtuse is NOT what development is about. May suite frontend consultancies that profit by hours and lock in, but not the rest of us.

./rant

Thanks Carson and hello 😄

Is there a way to simplify this?

<a href="/contact/2" hx-get="/contact/2" hx-push-url="/contact/2">Name</a>

? Without a href and the href being the same value, the link wont appear as a proper link with preview, without the push url it wont fix the address par. for the replacement, you kinda want all 3

Check out Boosting: https://htmx.org/docs/#boosting

I think that's what you're looking for

interesting. thanks @bland-coat-6833

does

hx-boost

not work the same on form?

<form method="POST" action="/contact/<?=$id?>" hx-target="#content" hx-boost="true">

doesnt do the url-push thing

Yeah - doesn’t do it for forms: https://htmx.org/attributes/hx-boost/

easy enough to add a push url there i guess.

though the doc you linked to does seem to say that it will form for forms