Current section: Honeypot 6 exercises

Honeypot Fields for Form Security


00:00 Let's go to our sign up and we'll come here and swap out this section with the Honeypot inputs from Remix Utils. And if we take a look at this now, we'll see we've got this div now has an ID,

00:14 an ARIA hidden true and style display none. It also has a label that says please leave this field blank, that is customizable. And we also have the input, that's the actual Honeypot. It also includes an autocomplete nope, so that the browsers won't autocomplete things. So again,

00:32 having a library for something like this, really great idea because it allows us to cover cases that we may not have thought of ourselves. And then on top of this, we could actually just change this to name double underscore confirm just to match what the library is doing. But it'd be even

00:48 better if the library can validate its own Honeypot. And so what we're going to do is come in here to utils and make a Honeypot.server to handle the server side of all of our Honeypot stuff.

01:00 And so we're going to make a Honeypot object from new Honeypot from Remix Utils. And then we're also going to export that. And then you can configure this in a bunch of different ways. We're going

01:14 to leave it blank for right now. We'll save this over here. And now we can use that Honeypot with a check on our form data and save that. Then if we fill this in incorrectly, so we add

01:31 a value to this, we say $0 value equals high, and then submit A at B.com. And now we get Honeypot input not empty. So that's exactly what we were looking for. If we try again A at B.com, uh-oh,

01:47 we're missing Honeypot valid from input. So this is kind of a tricky thing. But there is a feature of Honeypots or the Honeypot utility from Remix Utils that will check how quickly the Honeypot

02:02 was filled in. And so the valid from input is a special input that will be rendered in some cases to say this is when this form was generated in the first place. And we're not rendering that

02:17 right now because our setup is not totally complete here. So what we need to do is actually disable that for right now. So we're going to say valid from field name is null to disable that

02:30 particular field and that check. So if we come over here again and try this A at B.com, then that will work. We'll dive in a little bit deeper on this particular field in the next step.

02:44 So in review, we removed our own custom Honeypot and added the Honeypot fields input from our Remix Util. And that rendered for us this div with the label and input similar to what we

03:02 had before, which is maybe a little bit more thought out. And then we have this Honeypot.check that we call with the form data so it can do its check. Now we do still have this extra credit that we'll talk about here really quick. What this does is it's going to throw an error and it's just

03:18 like a regular error. So if I add a value to this again and say A at B.com, then the error that we get is caught by our error boundary. It looks fine. If we look at our network though, that's

03:32 going to be a 500 error. 500 error says I did something wrong, not you. That's incorrect. We don't want to send a 500 error. So we're going to follow through with this extra credit right here and we're going to move this in a try catch. And it will say if the error is an instance of a spam

03:51 error from our Honeypot server util, then we can throw a new response that says invalid form and status 400. And otherwise we'll just throw the error because we don't know. Maybe there was

04:09 something weird that happened and that is a server error. So let's try this once more. This is the last time for this step of the exercise. Add that value to A at B.com and boom, we get a 400

04:21 invalid form. We look at the network and here it is. We get that status of 400 exactly as we desired. So that is how you do the very basic implementation of the Honeypot from RemixUtils. We've got some more work to do though, so let's keep moving forward.