Build An Uptime Monitor with Inertia

Sign in Get started

This episode is for members only

Sign up to access "Build An Uptime Monitor with Inertia" right now.

Already a member? Sign in to continue

Playing

29. Authorizing the endpoint details

Episodes

0%

Your progress

Total: 4h 59m
Played: 0m
Remaining: 4h 59m

Join or sign in to track your progress

01. Introduction

01. Introduction and demo

02. A fresh Inertia project

02. Sites

03. Site and dashboard setup

04. Building the site selector dropdown

05. Making use of API resources

06. Setting the default site

07. Setting up Vue modals

08. Creating a site

03. Endpoints

09. Setting up endpoints

10. Enum endpoint frequencies

11. Creating the endpoint form

12. Storing an endpoint

13. Validating and authorizing endpoint stores

14. Normalizing the endpoint location

15. Displaying endpoints

16. Deleting endpoints

17. Toggling inline editing for endpoints

18. Applying a watcher to the endpoint form

19. Storing endpoint edits

04. Checking endpoints

20. Determining endpoints to check

21. Creating a job to perform a check

22. Making an HTTP request

23. Scheduling checks every second

24. Setting up the check relationship

25. Updating the job

26. Showing the last status

27. Expanded list of checks

28. The response body modal

29. Authorizing the endpoint details

30. Calculating uptime for endpoints

05. Queuing

31. Setting up queues

32. Queuing the endpoint check

06. Email notifications

33. Setting up email in Laravel

34. Site model email notification storage

35. Adding email addresses via the UI

36. Listing and deleting email addresses

07. Downtime notifications

37. Observing when to notify

38. Creating an endpoint down notification

39. Creating an endpoint recovery notification

40. Making the emails a bit friendlier

08. Extras

41. Deleting sites

42. Eager loading

43. Recovery notification bug

44. No sites fix and placeholder

Transcript

00:00

A really quick fix before we finish up on our endpoint index just here, this one, we didn't authorize this request. Now we know that over on our endpoint policy, we have the ability to update, destroy or check against this. We want to add one in here to say

00:18

can we view this or show this. So I'm going to go ahead and call this show, I think that makes sense, or list or whatever you want to call it. You could even create a generic touch to see if a user just has permission in general. So let's call this show and from the endpoint that we get passed in, of course the check is exactly the same here, we just want to make sure that the user has access

00:41

to this via the site that they own. So now that that's in there, we can go ahead and authorize this. Now of course you can authorize this directly within the controller, so we could say can we show this endpoint and that would work as normal. So we see that we've got permission to do this and if the id differs then it's not going to work. But again across our app we've been using

01:03

form requests, so I always like to keep things as consistent as possible and even if we're not posting through here, we can still create a form request to at least authorize this. So let's go ahead and do that now. Let's create out a form request here and keep the naming convention the same. If we look at the form request that we've got already, it's endpoint destroy controller,

01:22

endpoint store controller update. So we're gonna name this, if we just go ahead and make out a request here, endpoint and we could say endpoint index request. I think that actually makes a little bit more sense because technically this is an index, but then again we're showing this via root model binding. So yeah let's keep this to show, endpoint show controller request. I think

01:48

that makes a lot more sense. Okay so we can swap this out straight away. Endpoint show request and we're done. So we can go into here and the rules obviously we don't care about because we're just getting this, but from here we can do exactly the same thing. So this user can show this endpoint. So now everything is nicely tucked away in a form request. Our controller here is nice and clean.

02:12

I'll get rid of the eager loading note because we're going to come back to that later and there we go. So if we come over, sure enough it still works. So a quick fix up there. Of course that's really important because otherwise anyone would be able to type in any endpoint id and see information about that, which is not good.

Episode summary

In this episode, we notice a missing authorization check on our endpoint's index (or "show") action. This is a pretty important security detail—without it, anyone could access the details of any endpoint just by guessing or supplying an ID!

So, we quickly remedy this by adding a new method to our Endpoint Policy, specifically for checking if a user can 'show' or view an endpoint. The logic stays similar to our other policy methods: making sure the current user owns the resource they're trying to access.

To keep our codebase consistent, we wrap this check in a form request, even though this is a GET operation. We create a new EndpointShowRequest for authorization, swap it into the controller, and keep everything nice and tidy. As a result, our controller stays clean, all our authorization logic is centralized, and we remain consistent with our previous approach for other actions like update and destroy.

At the end, we test things out and confirm it's all working correctly! With this fix in place, our app's endpoint details are locked down and only visible to the right users.

Episode discussion

No comments, yet. Be the first!