Planning your Laravel and VueJS SPA Application Admin Section

As your application grows, more users join and more actions take place, an administration section becomes a higher and higher priority. Dynamically managing content, users, etc. through GUI is preferred and you can add other admin users to help off load the work. Within an API driven single page application, the same tools are used as a standard request application, but a few lenses have to be looked through regarding app security and functionality. With an application like Roast and Brew, where it’s open to the internet to add content, different administrative permissions need to be applied before things get out of line.

This specific tutorial in the course is an introduction to planning what we want on our administration side and what permissions we need. Now some would argue that this should be done right away and they have a valid point. However, these tutorials can be used at the beginning of an application to plan your user permissions, or if you are implementing them with a baseline application already in place. Since we are using Laravel Laravel – The PHP Framework For Web Artisans, which has Gates and Policies: Authorization – Laravel – The PHP Framework For Web Artisans, we will writing specifically on how to secure routes, resources, and methods with these features. I will be using Roast and Brew as the example app of course, but I will make these tutorials generic enough to implement into your own API Driven application.

There are a few things that come to mind with adding an admin side to an SPA such as viewing an admin page without being an admin and handling rogue requests from non admin users. We will be going covering all of this.

Just recently Laravel Nova was announced and takes care of a load of admin side functionality. Of course, use that if it fits your use case. The goal of these next tutorials will be more focused on Single Page App security. Of course we will touch on the admin side of approving and denying actions but will focus more on hiding information from a user in an SPA and blocking off sections of the app based off of permissions.

How We Will Handle Public Actions

Before we added permissions (insert winning argument against doing permissions first here), anyone can add, edit, or delete cafes. We had it this way simply to build an app, implement some CRUD methods and move forward. Now that people are using the app (once again, winning argument for planning an app here), we need to add some permissions.

We also need a process to handle changes to entities when they get updated. A simple solution is to track actions. If the user CAN do an action, then we will publish the action right away. If the user CAN NOT do an action, it goes into a queue to be reviewed. This will also transfer into a history for each cafe. The focus of these next few tutorials won’t be so much on these actions, even though they will be discussed, the tutorials will focus on the user permissions required for creating and approving actions.

We will be doing a lot of editing to existing routes. I will not be writing about all of the route edits since they are all very similar and it would get boring and cumbersome. I will also be generalizing the security so you can implement it in your apps easily. Of course if there are any questions, ask in the comment section below. All of the edits will also be pushed to GitHub for you to browse and see how we implemented them.

We will also be tracking who submitted the actions, whether it was approved or denied, and the type of action. This will allow us to see users who submit quality data in the future and maybe adjust their permission level.

To sum up, users will submit cafes, edit cafes, delete cafes. Each of these will be an action. If the user has proper permissions, these actions will go into affect right away. If the user does not have proper permissions, an admin will have to approve the actions.

Plan Security

I will mention it once again, this could definitely and probably should be done when you are first starting your app. However, if it isn’t the case, it’s never to late to implement permissions. In our application, we will have 4 types of users.

Super Admin

The super admin will have the highest level of permissions. They will be able to do everything in the app. Some of the features of the super admin will be direct adding of admins (2nd highest level), direct editing of entities, and adding of entities NOT open to the public (such as brew methods and coffee resources).

Admin

Admins will have permissions to directly edit entities and also approve additions and actions on entities. They will also will be able to add coffee shop owners (3rd highest level).

Company Owner

This user can simply edit their own company and the cafes associated with it. If they own the company all edits they have for the company will be approved without an admin’s consent. Any other edits, or additions will have to be approved by an admin. Any edits to their own coffee shop can be approved by them.

General User

This is a new user to the application. They can submit edits, deletions, additions, but all of these will have to be approved by a user with more permissions.

You could count guests (users without an account) as the fifth group, but they can only view the data available.

Conclusion

We now have our structure in place it’s time to rock and roll with implementing our admin section. The next tutorial we will begin to add some Laravel Gates and Policies. If you have any questions, let me know in the comments below!