@permitio/permit-strapi 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +139 -0
- package/dist/admin/App-BmwAac5t.js +1029 -0
- package/dist/admin/App-DGsvV3Vz.mjs +1027 -0
- package/dist/admin/en-B4KWt_jN.js +4 -0
- package/dist/admin/en-Byx4XI2L.mjs +4 -0
- package/dist/admin/index-C2zppPZ6.js +73 -0
- package/dist/admin/index-CUo5x9bE.mjs +72 -0
- package/dist/admin/index.js +4 -0
- package/dist/admin/index.mjs +4 -0
- package/dist/admin/src/index.d.ts +10 -0
- package/dist/server/index.js +1111 -0
- package/dist/server/index.mjs +1111 -0
- package/package.json +96 -0
package/README.md
ADDED
|
@@ -0,0 +1,139 @@
|
|
|
1
|
+
# permit-strapi
|
|
2
|
+
|
|
3
|
+
A Strapi 5 plugin that connects your Strapi application to [Permit.io](https://permit.io) for fine-grained access control. It supports RBAC, ABAC, and ReBAC out of the box, and enforces authorization on every API request without you having to touch your controllers.
|
|
4
|
+
|
|
5
|
+
## What it does
|
|
6
|
+
|
|
7
|
+
By default, Strapi's built-in permissions work at the role level — a role either has access to a content type or it doesn't. This plugin adds a second enforcement layer that sits between the request and your controllers, giving you much more control over who can access what and under what conditions.
|
|
8
|
+
|
|
9
|
+
Once installed and connected, the plugin:
|
|
10
|
+
|
|
11
|
+
- Intercepts all `/api/` requests that carry a Bearer token
|
|
12
|
+
- Verifies the token and identifies the user
|
|
13
|
+
- Calls Permit.io to check if the user is allowed to perform the action on that resource
|
|
14
|
+
- Returns a 403 if the check fails, or passes the request through if it succeeds
|
|
15
|
+
|
|
16
|
+
Your existing Strapi setup does not need to change. The plugin registers a global middleware that handles enforcement automatically.
|
|
17
|
+
|
|
18
|
+
## Requirements
|
|
19
|
+
|
|
20
|
+
- Strapi 5
|
|
21
|
+
- Node.js 22 (Node 23 is not supported by Strapi)
|
|
22
|
+
- A [Permit.io](https://permit.io) account
|
|
23
|
+
- For ABAC and ReBAC: a self-hosted Permit.io PDP. The cloud PDP only supports RBAC.
|
|
24
|
+
|
|
25
|
+
## Running a self-hosted PDP
|
|
26
|
+
|
|
27
|
+
If you plan to use ABAC or ReBAC, you need a self-hosted PDP. The quickest way to run one locally is with Docker:
|
|
28
|
+
|
|
29
|
+
```bash
|
|
30
|
+
docker run -p 7766:7000 \
|
|
31
|
+
--env PDP_API_KEY=<your-permit-api-key> \
|
|
32
|
+
permitio/pdp-v2:latest
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Use `http://localhost:7766` as the PDP URL when configuring the plugin.
|
|
36
|
+
|
|
37
|
+
## Installation
|
|
38
|
+
|
|
39
|
+
```bash
|
|
40
|
+
npm install @permitio/permit-strapi
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
After installing, restart your Strapi server. The plugin will appear in the admin sidebar under the Permit.io section.
|
|
44
|
+
|
|
45
|
+
## Getting started
|
|
46
|
+
|
|
47
|
+
1. Open the plugin in the Strapi admin panel
|
|
48
|
+
2. Enter your Permit.io API key and PDP URL
|
|
49
|
+
3. Click Connect — the plugin will validate the key and sync your content types and roles to Permit.io automatically
|
|
50
|
+
|
|
51
|
+
From there, you can configure which content types are protected, set up attribute mappings for ABAC, or enable ReBAC per content type.
|
|
52
|
+
|
|
53
|
+
## How authorization works
|
|
54
|
+
|
|
55
|
+
The plugin uses a two-layer model:
|
|
56
|
+
|
|
57
|
+
**Layer 1 — Strapi Users & Permissions**: controls which roles have access to which endpoints at all. You should grant full access per role here and let the plugin handle the fine-grained enforcement.
|
|
58
|
+
|
|
59
|
+
**Layer 2 — Permit.io middleware**: calls `permit.check()` on every request with the user identity, the action (find, findOne, create, update, delete), and the resource. Permit.io evaluates your policy and returns allow or deny.
|
|
60
|
+
|
|
61
|
+
Both layers must pass for a request to go through.
|
|
62
|
+
|
|
63
|
+
## RBAC
|
|
64
|
+
|
|
65
|
+
Role-based access control is the default mode. When you connect the plugin, it syncs your Strapi roles to Permit.io. User role assignments are kept in sync automatically — when a user is created, updated, or deleted in Strapi, the plugin reflects those changes in Permit.io in real time.
|
|
66
|
+
|
|
67
|
+
To configure RBAC policies, use the Permit.io dashboard to set which roles can perform which actions on which resources.
|
|
68
|
+
|
|
69
|
+
## ABAC
|
|
70
|
+
|
|
71
|
+
Attribute-based access control lets you write policies based on properties of the user or the resource. For example: only users in the `us` region can access products with `region: us`, or only users with `clearance: elevated` can access confidential records.
|
|
72
|
+
|
|
73
|
+
To enable ABAC:
|
|
74
|
+
|
|
75
|
+
1. Make sure you are using a self-hosted PDP
|
|
76
|
+
2. Open the plugin's ABAC Attribute Mapping section
|
|
77
|
+
3. Select which user fields to include as user attributes (e.g. `region`, `department`)
|
|
78
|
+
4. Select which fields on each content type to include as resource attributes (e.g. `region`, `confidential`)
|
|
79
|
+
5. Save — the plugin will re-sync the resource schemas to Permit.io
|
|
80
|
+
|
|
81
|
+
The plugin fetches user and resource attributes at request time and passes them to `permit.check()`. For single-resource endpoints (`GET /api/posts/:id`), both user and resource attributes are included in the check. For list endpoints (`GET /api/posts`), the plugin performs a bulk check — it fetches all results, runs `permit.check()` against each one with its resource attributes, and filters out any the user is not allowed to see.
|
|
82
|
+
|
|
83
|
+
Relation fields are supported in attribute mappings. When a content type has a relation field (e.g. `company`), the plugin flattens it to `companyId` (the related record's ID) for both resource and user attributes. Use the flattened name (e.g. `resource.companyId`, `user.companyId`) when writing conditions in Permit.io.
|
|
84
|
+
|
|
85
|
+
You configure the actual access rules (user sets, resource sets, condition set rules) in the Permit.io dashboard.
|
|
86
|
+
|
|
87
|
+
## ReBAC
|
|
88
|
+
|
|
89
|
+
Relationship-based access control ties permissions to the relationship between a user and a specific record. For example: a user can edit a document because they created it, or they can view it because someone shared it with them.
|
|
90
|
+
|
|
91
|
+
To enable ReBAC for a content type:
|
|
92
|
+
|
|
93
|
+
1. Open the ReBAC Configuration section in the plugin
|
|
94
|
+
2. Enable ReBAC for the content type
|
|
95
|
+
3. Set the creator role — the role assigned to users when they create a record (defaults to `owner`)
|
|
96
|
+
4. Define instance roles — the roles that can be assigned on individual records (e.g. owner, editor, viewer)
|
|
97
|
+
5. Save the roles — they will be synced to Permit.io as resource roles
|
|
98
|
+
6. Use the Sync Instances button to push all existing records to Permit.io as resource instances
|
|
99
|
+
|
|
100
|
+
New records are synced to Permit.io as resource instances automatically when created. Deleted records are removed from Permit.io automatically.
|
|
101
|
+
|
|
102
|
+
One thing to be aware of: automatic creator role assignment is not yet implemented. When a record is created, the instance exists in Permit.io but no relationship is assigned to the creator. You need to assign instance roles manually from the Permit.io dashboard or via the Permit.io API after creation.
|
|
103
|
+
|
|
104
|
+
## Syncing users
|
|
105
|
+
|
|
106
|
+
New users are synced to Permit.io automatically when they register. If you have existing users, use the Sync All Users button in the User Sync section to push them to Permit.io in bulk.
|
|
107
|
+
|
|
108
|
+
## Protected resources
|
|
109
|
+
|
|
110
|
+
By default, all content types are protected. You can toggle individual content types off in the Protected Resources section if you want Permit.io enforcement to skip them entirely.
|
|
111
|
+
|
|
112
|
+
## Fail open behavior
|
|
113
|
+
|
|
114
|
+
If the Permit.io client is not initialized or if the PDP is unreachable, all requests pass through without enforcement. This means a misconfigured or disconnected plugin will not break your API — it just stops enforcing until you reconnect.
|
|
115
|
+
|
|
116
|
+
## Contributing
|
|
117
|
+
|
|
118
|
+
The plugin uses [yalc](https://github.com/wclr/yalc) for local linking during development.
|
|
119
|
+
|
|
120
|
+
In the plugin directory:
|
|
121
|
+
|
|
122
|
+
```bash
|
|
123
|
+
npm install --legacy-peer-deps
|
|
124
|
+
npm run watch:link
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
In your Strapi project:
|
|
128
|
+
|
|
129
|
+
```bash
|
|
130
|
+
npx yalc add @permitio/permit-strapi
|
|
131
|
+
npx yalc link @permitio/permit-strapi
|
|
132
|
+
npm install
|
|
133
|
+
nvm use 22
|
|
134
|
+
npm run develop
|
|
135
|
+
```
|
|
136
|
+
|
|
137
|
+
## License
|
|
138
|
+
|
|
139
|
+
MIT
|