Current section: Honeypot 6 exercises

Honeypot Protection


00:00 Let's start out by going to our root. And we have something new from Kelly, the coworker here. So before, we had export default on the app. Now we need to render our app within a provider so that everything in our app has access to that. And we could definitely put the provider around the document

00:17 and all of that stuff, but that would just be a lot of work. And so instead, we're going to make another component called app with providers. That's the thing that we will default export. And then we can just wrap the app, and then we don't have to worry about it. So let's first go to our server side because we need to get the props that

00:36 includes the thing that will identify when the fields were created. So I'm going to call this the honey props. And we're going to say honeypot.getInputProps. That's the honeypot from our utility here. And then we can say honey props right there.

00:56 And then down in here, we can get our loader data. And we'll render our app within the honeypot provider. And we'll stick that there. And then we'll say spread the data.honeyprops. So you can take a look at that. Feel free to dive into the implementation if you like.

01:14 This has the valid from field name, so we can configure that, the name field name, and the encrypted valid from value. So with all of that, any time we render the honey input component, it will have access to those

01:30 so that it knows those values so that when we ultimately do the honeypot.check, it is checking the same values and all of that correctly. So with that, we are almost there. We can take a look at our output here. Nothing really has changed. But if we come over here and turn this off,

01:49 then the default behavior will take into account. And here we have our inputs from confirm. And so that should not be filled in even by a bot because it's read only. But maybe they'd fill it in, and that would also invalidate it. But the value here is not something

02:07 that the bot could generate either because it's encrypted. So we do want to have this here, but not during our testing, both development as well as testing. And so we have this environment variable set up that we will talk about at a future time. It's called processenvtesting. And if that is set to true, which

02:26 it is set to true in development, then we want to disable the valid from field. And so we set it to null. Otherwise, we'll allow the default behavior. So we'll set it to undefined. So if I save this, then we'll see we've got our field is not there for determining

02:45 whether the user submitted it really fast. So that way, when we're running our tests, we don't run into that problem. But if I wanted to, we could go to our index.js and disable this behavior. And then we need to restart our server and start it up again.

03:01 And with that, now we can refresh and take a look at this. And we'll see we've got our from confirm fields and all of that. So a really quick review. In our loader, we call our honeypot utility and call getInputPrompts.

03:19 This actually also supports some configuration as well that you can take a look at. We get our honey props. And we pass that to our UI, which then renders all of our components inside of this honeypot provider with those props.

03:34 And then ultimately, in our signUp component, when we render this honeypot inputs, it grabs that context value and renders things appropriate based on that. And that is how we get our from confirm field in here

03:51 to validate that the form wasn't sent too quickly and submitted too quickly, like faster than a human could possibly submit it.