Headless CMS

Definitions & benefits

Tools & Concepts

Open source

Features

Authentication

Custom plugins & Marketplace

Webhooks

Multilingual CMS

APIs

Dynamic Zones

User roles & permissions

Content Modeling

Security & Privacy

Use Cases

Ecommerce

Blog

Forum

About Strapi

Life at Strapi

Releases & Roadmap

Events

Community

News

The Tutorials section covers an introduction to Strapi, some advanced technical content, product updates and releases. From basic workaround to in-depth development guides. 

Tutorials

How tos

Get all the latest updates, news and events.

Subscribe to the newsletter 📣


## **An Introduction to Strapi**

[Strapi](https://strapi.io/) is the next-gen headless CMS. It is open-source, Javascript, enabling content-rich experiences to be created, managed, and exposed to any digital device.

The name Strapi summarizes what the open-source project does well, allowing you to create your API from scratch using a point-and-click interface. Developers can easily personalize their API for custom implementation or custom logic.

## **Why Did We Build Axolo and What is Axolo?**

We believe efficient communication when reviewing, and writing code is essential for productive tech teams. [Axolo](https://Axolo.co) is a tool to enable developers to engage and communicate easily around pull requests. We integrate via GitHub and Slack. Axolo creates a temporary Slack channel for every pull request so that you can discuss the pull request with your colleagues quickly and with the proper context (code review comments, code comments, GitHub checks, and GitHub actions).

### **How Do We Use Strapi at Axolo?**

Strapi runs our backend and handles all the programming logic with our database. Strapi helped set up the models and create routes to interact with the GitHub and Slack API.  It also gives an excellent base for scaling a project with the proper structure (controllers, services, API, policies, models, etc.).

### **What are Strapi Policies:**

According to the [Strapi documentation](https://docs.strapi.io/developer-docs/latest/development/backend-customization/policies.html#implementation), "Policies are functions that execute specific logic on each request before it reaches the controller. They are mostly used for securing business logic."
Policies are placed in your router and can be found under your models `/routes` folder. Usually inside `api/{modelname}/routes/{modelname}.js`.

### **What’s So Great About Strapi Policies?**

Strapi policies allow you to create rules for your routes. Whenever you need to implement a rule for a route, you can add a policy to your router for the selected route. It helps keep your code DRY (don’t repeat yourself) and prevents your controller from being surcharged. I personally often find myself re-using routes I made a while ago.

### **Creating a Strapi policy**

To create a policy, you need to create a folder in your `src` called `policies.` You can give it the name that you feel is more appropriate. The name of the file will be the name of the policy in your routes.

![File structure for policies in Strapi](https://paper-attachments.dropbox.com/s_8000E7EE5074F55B06D019B0BD8F8BD81F2AAB23A2140EF82694114A95EABC4E_1650273475586_CleanShot+2022-04-18+at+11.17.46.jpg)

### **Applying a Policy to a Route**

To apply a policy to a route, you need to add a key to your route object [](https://docs.strapi.io/developer-docs/latest/development/backend-customization/policies.html#implementation)as stated in [the Strapi documentation](https://docs.strapi.io/developer-docs/latest/development/backend-customization/policies.html#implementation):

```
    // path: ./src/api/restaurant/routes/router.js 
    module.exports = {
     routes: [
       {
         method: 'GET',
         path: '/restaurants',
         handler: 'Restaurant.find',
         config: {
           /**
             Before executing the find action in the Restaurant.js controller,
             we call the global 'is-authenticated' policy,
             found at ./src/policies/is-authenticated.js.
            */
           policies: ['global::is-authenticated']
         }
       }
     ]
    }
```

The *policies* key takes an array as an argument. You can add multiple policies to a single route if you like. Also, the policy name is the name of the file.

**How do we use Policies at Axolo:**
There are three (3) main ways we use policies at Axolo. Here is the list with code examples:


1. **Is-admin policy:**

This policy helps us determine if somebody making a request is an admin within his organization.

Within Axolo we have two types of users:

- An **Administrator** who can edit the settings for their organization, 
- **Engineers** who use our service day-to-day.

Both types of users are signed in to our service but only the administrator can edit the settings. To add a layer of security to our frontend, we used a Strapi policy, see below:

```
    // path: ./src/policies/is-organization-admin.js
     
    module.exports = (policyContext, config, { strapi }) => {
     if (policyContext.state.user.isAdmin) {
       return true
     }
     return 401;
    };
```

2. **Is a paying customer policy:**

Some Axolo features are dedicated to paid customers. We’ve ensured a non-paying user cannot access those routes by adding an `is-paying-organization` policy. Our user model has and belongs to an organization model.

```
    // src/policies/is-paying-org.js
    module.exports = (policyContext, config, { strapi }) => {
     const id = policyContext.state.user.organization;
     const organization = await strapi.query('organization').findOne({ id });
     const { plan } = organization;
     if (plan === 'professional' || plan === 'trial') {
       return true;
     }
     return false
    };
```

3. **To know the day of the week:**

We use Heroku as a hosting platform and Heroku scheduler as a cron job. These cron jobs work by calling a specific route in our backend. Heroku only allows three possibilities for the cron job to be contacted: every 10 minutes, every hour, or every day. Since some of our actions only need to be run during the week, on a specific day, or only during weekends, we have a dedicated policy for each of those cases. 

Here is an example of a policy that checks if it's a weekday (Monday, Tuesday, Wednesday, Thursday, or Friday).

```
    // src/policies/is-weekday-today.js
    const moment = require('moment');
     
    module.exports = (policyContext, config, { strapi }) => {
     const date = moment();
     const day = date.day();
     if (day >= 1 && day <= 5) {
         return true
     }
     return false
    };
```

## **Conclusion**

Policies are helpful to keep your controllers DRY (don't repeat yourself). If you see yourself using the same code over two controllers or think you could be reusing some of the logic you implement in a controller, it probably is a good idea to create a policy for that.

Do you have any other use case for policies? Share them below so that anyone reading this article can get inspired by your way of having policies.

