SECURING CONTENT: A Custom Content Management Dashboard.

This is a submission for the Permit.io Authorization Challenge: API-First Authorization Reimagined What I Built I built a Content Management Dashboard, I was thinking of a customized CMD, where operations are modularized and in the spirit of API-first approach. The application is ready for use, secure and lightweight as it heavily employ API-first methodology. I used Permit.io to simplify the authorization task here, clear-cut operations, roles, resources, debugging and non-repudiation. All website managers want to have a view of posts, do CRUD operations on them. Try to retain and engage subscribers using newsletter and discover bugs without touching the always risky terminal and the in-comprehensive cPanels. My application do just that with a possibility to use it side by side with the generic CMS systems. Demo The link to github repository:https://github.com/jackcodes64/cm-dashboard/ My application has 3 tabs in the highest level of abstraction:- Login and Home Users, writer or admin logs in for authentication, the process also double as a fetch for tokens needed tokens for in-app authorizations. POST This is the core section of my application. It provides for viewing of posts, updating, deletion, and creation of new post with all needed attributes The post tab further houses the highly powerful ALTER, there you can do the remaining 3 operations. All operations in this section are accessible to all users. Post can be filtered based on categories or specified by the ideally unique heading. The operations in alter: USERS This table allow for two operations only, read and delete. The delete functionality only accessible to the admin. Its faded out and unusable in writer instances. The CSV file also can be downloaded using the button for email services. 4.BUGS This is the last tab, all server side bugs are accessible from here, no need to go stumbling on the server terminal tracing them. The tab is entirely inaccessible to the writer, blotted off and cursor is at "not-allowed". And in admin instance: In the admin instance, the bugs can be marked as resolved:- Project Repo Github: https://github.com/jackcodes64/cm-dashboard The link to frontend: https://cm-dashboard-xbo3.vercel.app/ NOTE: password:2025DEVchallenge, i missed the uppercase C. My Journey It was after my exams when i realized i need more projects to reinforce my newly acquired backend knowledge. The CMS we were designing for project in class had a lot of authentication and authorization, role-based access, that when i see a SaaS having solved the authorization overhead this comprehensively to let you focus on your project's core logic, i had to experience it. Implementation My project is API heavy and no core operation is done in the frontend. I wanted to develop an application truly dependent on external policies rather than the traditional spaghetti of hardcoded logic. I had to do research on Permit.io to see if it was feasible having joined late. I then started by fumbling with integration designed. Mulled it over and decided to use pdp as it had a clear example in Permit.io website. Chose "quick permit" in the "Connect Environment" section, it was the fastest way to integrate and start having fun. I chose node.js language -- it's my runtime environment, allows me to use JavaScript in whole project. After the selection of technology to use, a brief but clear and easy to follow instruction proceeded, so clear you're told: "touch test.js". And that's how i tested authorization of "John Doe". Easier than i imagined, but not miraculous ---you have to plumber it right. Challenges Was first entrapped in poking of the SDK to do something, later figured out i need to use the cloud hosted PDP. Again, for a while i wallowed around my project, trying to figure out errors, only to realize that a detailed Error Log section exploited all possible sources of faults. What i learned Authorization is not just security, it's UX too. API-first authorization is the way to go, almost halves your time in such small projects. Dev tasks are better simplified, modularised and re-used: No time wastage in reinventing the wheel. Drop the option, don't rely on the user being ethical or responsible. Some SaaS like Permit.io, provides for non-repudiation, we can always trace the action back to a user. API-First Authorization Problem Scope I needed to design a Content Management Dashboard for two types of users, the admin and the writer(s). The goal was clear, everybody accesses just what they should. Permission Model I implemented permission in two levels, in the front end and the back end. ROLES: newuser/writer, admin RESOURCES: debugPage, post, and sendEmail OPERATIONS: All the CRUD operation but on level-based authorization. i. Frontend: Basically backend authorization but designed into a really powerful component - "Per

May 5, 2025 - 04:56

SECURING CONTENT: A Custom Content Management Dashboard.

This is a submission for the Permit.io Authorization Challenge: API-First Authorization Reimagined

What I Built

I built a Content Management Dashboard, I was thinking of a customized CMD, where operations are modularized and in the spirit of API-first approach. The application is ready for use, secure and lightweight as it heavily employ API-first methodology. I used Permit.io to simplify the authorization task here, clear-cut operations, roles, resources, debugging and non-repudiation.
All website managers want to have a view of posts, do CRUD operations on them. Try to retain and engage subscribers using newsletter and discover bugs without touching the always risky terminal and the in-comprehensive cPanels. My application do just that with a possibility to use it side by side with the generic CMS systems.

Demo

The link to github repository:https://github.com/jackcodes64/cm-dashboard/
My application has 3 tabs in the highest level of abstraction:-

Users, writer or admin logs in for authentication, the process also double as a fetch for tokens needed tokens for in-app authorizations.

POST

This is the core section of my application. It provides for viewing of posts, updating, deletion, and creation of new post with all needed attributes

The post tab further houses the highly powerful ALTER, there you can do the remaining 3 operations. All operations in this section are accessible to all users. Post can be filtered based on categories or specified by the ideally unique heading.

The operations in alter:

USERS This table allow for two operations only, read and delete. The delete functionality only accessible to the admin. Its faded out and unusable in writer instances.

The CSV file also can be downloaded using the button for email services.

4.BUGS
This is the last tab, all server side bugs are accessible from here, no need to go stumbling on the server terminal tracing them. The tab is entirely inaccessible to the writer, blotted off and cursor is at "not-allowed".

And in admin instance:

In the admin instance, the bugs can be marked as resolved:-

Project Repo

Github: https://github.com/jackcodes64/cm-dashboard
The link to frontend: https://cm-dashboard-xbo3.vercel.app/
NOTE: password:2025DEVchallenge, i missed the uppercase C.

My Journey

It was after my exams when i realized i need more projects to reinforce my newly acquired backend knowledge. The CMS we were designing for project in class had a lot of authentication and authorization, role-based access, that when i see a SaaS having solved the authorization overhead this comprehensively to let you focus on your project's core logic, i had to experience it.

Implementation

My project is API heavy and no core operation is done in the frontend. I wanted to develop an application truly dependent on external policies rather than the traditional spaghetti of hardcoded logic.
I had to do research on Permit.io to see if it was feasible having joined late. I then started by fumbling with integration designed. Mulled it over and decided to use pdp as it had a clear example in Permit.io website.

Chose "quick permit" in the "Connect Environment" section, it was the fastest way to integrate and start having fun.

I chose node.js language -- it's my runtime environment, allows me to use JavaScript in whole project.

After the selection of technology to use, a brief but clear and easy to follow instruction proceeded, so clear you're told: "touch test.js". And that's how i tested authorization of "John Doe". Easier than i imagined, but not miraculous ---you have to plumber it right.

Challenges

Was first entrapped in poking of the SDK to do something, later figured out i need to use the cloud hosted PDP.
Again, for a while i wallowed around my project, trying to figure out errors, only to realize that a detailed Error Log section exploited all possible sources of faults.

What i learned

Authorization is not just security, it's UX too.
API-first authorization is the way to go, almost halves your time in such small projects.
Dev tasks are better simplified, modularised and re-used: No time wastage in reinventing the wheel.
Drop the option, don't rely on the user being ethical or responsible.
Some SaaS like Permit.io, provides for non-repudiation, we can always trace the action back to a user.

API-First Authorization

Problem Scope
I needed to design a Content Management Dashboard for two types of users, the admin and the writer(s). The goal was clear, everybody accesses just what they should.
Permission Model
I implemented permission in two levels, in the front end and the back end.

ROLES: newuser/writer, admin
RESOURCES: debugPage, post, and sendEmail
OPERATIONS: All the CRUD operation but on level-based authorization.

i. Frontend: Basically backend authorization but designed into   a really powerful component - "PermissionGate". I import it into modules and customise it for UX like fading off options inaccessible by the user and having the cursor at "not allowed".

ii. Backend

Installed the SDK into my project directory: npm install permitio.
Imported the Permit module from "permitio".
Created a permit function from the top level function - Permit.
Created a checkpoint route attending to permission requirements from the frontend--made request using my API key and through the PDP.
Created a permit module for all backend authorizations. And that's it! Try it, I cannot think of an improvement!

I'm very proud of this work. Thank you for reading.