reCAPTCHA with Laravel
This episode is for members only

Sign up to access "reCAPTCHA with Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
05. Verifying the token with middleware

Episodes

0%
Your progress
  • Total: 49m
  • Played: 0m
  • Remaining: 49m
Join or sign in to track your progress

Transcript

00:00
figured out that we don't really want to be doing anything in here to verify this token. That means that we have to repeat ourselves in every single controller
00:07
that we send this token down to, and we don't really want to do that. So a really good place to put this validation of the token is in middleware, which means we can very easily just attach it to any of our routes. So let's go and create out some middleware in here. So we'll make out some middleware and let's call this
00:28
verify recapture token. Perfect. So let's go ahead and create that out, and we're gonna head straight over to the verify recapture token middleware, and in here let's just die dump on request and recapture token, just so we know that this is coming through. Now we want a really easy way to add this, and we don't
00:52
really want to have to new this middleware up every single time, and we want to be able to easily pass options into this later, like the threshold. So what we're gonna do is head over to our kernel under app and HTTP, and we're gonna add this as a named piece of middleware. So let's go ahead and copy
01:08
this line down, let's call this recapture, and then we're just going to go and reference that verify recapture token class in there. So we can just call this by its name now, much easier. So if we head over to our web routes, the way that Laravel breezes setup is it requires in a separate file which also registered
01:30
routes, and this is auth.php in the routes file, and this is where all of the routes for authentication are obviously. So we're gonna go over to this route here, which is the authenticated session controller, and we're gonna attach some middleware to this, and you guessed it, we're just going to reference it by
01:48
its name. So now when we submit that through, we've got that middleware, and that should just dump that out, dump that value out. Let's go and try this, so let's head back to our login form, and let's enter our details in here, hit login, and there we go. We get exactly the same result, but we've got some nice
02:04
middleware now that we can put on any of our routes, makes it much easier. So now for the good part, we're gonna go and actually make a request through to the Google API to verify this token. Now to do this, we can use the HTTP client directly within Laravel, which is built on top of Guzzle, but just provides a
02:23
really nice API for us to do this. So let's assign this a response first of all, and with the particular request that we're making, this needs to be sent down as form data. So really importantly, we need to add in a modifier when we send this request down as form. That's pretty much what we need to do there. Now the
02:42
next thing that we're going to do is go ahead and post this through to an endpoint. So that endpoint is on the Google documentation, but I'm just going to go ahead and grab this from my notes here. It's just recapture slash API slash site verify. So either grab that from the docs or copy that out, and the second
03:01
argument to this is an array of data that we want to send it down. So the two most important are the secret, because we need to authorize this in some way. We know that we've got that stored in config. And the second one is, sure enough, the token itself, which is confusingly called response. So that's
03:18
the token response that we get back. So we know where that token comes from. It comes from our request, and it comes from recapture underscore token. The secret we can very easily just grab from our config. So recapture dot secret. Remember that's the difference between the public and the
03:36
private secret key. Now optionally we can also pass an IP down, the user's IP address, which will help with the verification process. You don't need to do this, but I'm gonna go ahead and just send it down now because I'm just working locally. If you do want to grab this, you can grab this directly from your request,
03:53
and it's just the IP method that will give you the user's IP address. So there are the three things that we need to send down. Let's go ahead and grab the response from this. Now we need to choose how we want to get this response back. There's a couple of ways that we can do this. We can get this back as a
04:11
collection. We can get this back as an array. In our case we're going to get this back as an object because it kind of makes sense. Once we see the response we can then just very easily start to pluck stuff out of this. So I'm going to go ahead and just die dump on the response that we get back, and let's see
04:26
if this works. So we have the token being submitted with our form. We are now sending that off to Google's API, and we should get back a response here. So there's a couple of things that we need to take note of. The fact that this was successful, which at the moment it was. We don't really care about the timestamp,
04:45
although sometimes you might need to use that. Host name we don't really care about. Score is what we care about the most here. That is the threshold that we've already looked at. So basically what we now need to do is check if this was successful, and handle it if it wasn't. We then need to check if the
05:03
score is greater than a defined threshold that we've given, or greater than or equal to a defined threshold that we've given. And then if either of these things don't quite work we need to handle them in some way. So let's work on the first one, and that is if success was not true, something went wrong. So we can
05:23
just very easily, now that we've got this back as an object, check the response and check that success property, and see if it equals false. And if it is false we need to do something. Now I'm just going to die dump and say failed here, because we're going to handle this in a slightly different way. This could be for any
05:40
reason. It might be that your token is not quite right, or your API key is not quite right. It's more of a validation thing in terms of your data that you're sending down. So it shouldn't happen too often. The second thing we need to check is the threshold. So we're going to go ahead and manually code this in now, and
05:57
then a bit later on we're going to update this so we can actually choose our threshold or get it from config. So we're going to go ahead and grab the response score, and we're going to check if this is less than or equal to. So we're doing this defensively. We're checking if this is less than the threshold that we
06:13
want to give. So I'm going to put that as 0.8. So I think that's quite a nice threshold here. And if that fails then we're just going to say recapture failed. Of course we're not going to keep this die dump in there. We're going to change that out later. But at least we can see this working now. Okay so if we bump this
06:31
up to 1, because like we saw earlier that's quite an unrealistic threshold, if we head over and try this out we should get a failure and we get recapture failed. So it's at this point we can redirect the user back, flash a message, and tell them that this failed for whatever reason. So otherwise we're just going to
06:51
continue to the next request. So if this was successful this will go ahead and forward us over to actually submit the login form and it will sign the user in. So we've got two things that are defending us from something not working. Whether the request itself was not successful or whether the recapture
07:10
actually failed due to a bot or something like that. So I'm going to switch this threshold back to 0.8. Let's just take a real quick look at the flow with this being successful. And what you pretty much have now is a successful recapture validation. All we really need to do now is tidy this up so we can get
07:31
some custom error messages in there rather than dying and dumping. And allow the threshold to be very easily chosen. And of course create that custom blade directive so you can reuse this on any of your forms. So let's get on with that in the next few episodes.

Episode summary

In this episode, we're cleaning up our code by moving the reCAPTCHA verification into its own middleware. Instead of repeating the token validation in every controller or route, we create a dedicated VerifyRecaptchaToken middleware that can just be attached to any route we want to protect. This makes the code much tidier and reusable!

We set up the middleware and register it in Laravel's kernel so we can use it by a simple name (recaptcha) on our routes, like in the authentication flow. Then, we test it to make sure that when the user submits a login form, the token is being processed by our middleware.

After that, it's time to actually talk to Google's reCAPTCHA API. We use Laravel's HTTP client to send the necessary data (the token, secret key, and optionally the user's IP address) as a form POST, and grab the response as an object. We look at what's in the response—like the success flag and the all-important score. Depending on these, we handle failed or successful validations (for now, just with dd() calls to see what happens).

At the end, we discuss next steps: we'll clean up these responses so they don't just dump to the screen, let the threshold score be easily configurable, and create a Blade directive to reuse reCAPTCHA in any form. So now, we've got reCAPTCHA validation working in middleware, making our authentication routes safer and our code much cleaner!

Episode discussion

No comments, yet. Be the first!