User groups and restricted access to data

simontam · November 9, 2020, 4:35pm

I’m looking to use Strapi to group user accounts together (ex. users belonging to companies). Each company will have the same collections/model of data as the other but obviously I don’t want users from one company to be able to see the data from another company. Ideally I would also get to control what users within a company can see/do whatever.

Effectively the data itself is federated by users/groups but the model is common across my installation.

How have others solved this problem?

DMehaffy · November 9, 2020, 9:52pm

Hi @simontam

This is a common use-case and we haven’t totally implemented multi-tenancy yet (see: Multi-tenancy - Roadmap | Product Roadmap) but it can roughly be accomplished with some well written policies. I’ll leave you with our policy documentation but also with a bit of an older example of this in testing.

You are more than welcome to test out my rough example I made a few months back, but it may require some customization and I don’t generally recommend throwing a bunch of checks in a single policy and instead break them out into their own. This example was written for a user while I was twitch streaming one day.

Repo: GitHub - derrickmehaffy/testing-strapi-policies

Main policy for testing:

github.com

derrickmehaffy/testing-strapi-policies/blob/master/config/policies/isOrgMember.js

module.exports = async (ctx, next) => {
  let route = ctx.request.route;

  // Use these to log data coming from the user
  // Koa Docs: https://koajs.com/#request
  // console.log(ctx.request.route);
  // console.log(ctx.query)
  // console.log(ctx.params)
  // console.log(ctx.request.body)
  // console.log(ctx.state.user)

  if (ctx.state.user) {
  // FIND & COUNT
    if (route.action === "find" || route.action === "count") {
      // Two ways to handle this
      // Way 1: forcefully set the query params to filter

      if (Object.keys(ctx.query).length === 0) {
        ctx.query = {
          organisation: ctx.state.user.organisation

This file has been truncated. show original

Applied to a content-type:

github.com

derrickmehaffy/testing-strapi-policies/blob/master/api/post/config/routes.json

{
  "routes": [
    {
      "method": "GET",
      "path": "/posts",
      "handler": "post.find",
      "config": {
        "policies": ["global::isOrgMember"]
      }
    },
    {
      "method": "GET",
      "path": "/posts/count",
      "handler": "post.count",
      "config": {
        "policies": ["global::isOrgMember"]
      }
    },
    {
      "method": "GET",

This file has been truncated. show original

There is lot there to digest but the examples I gave kind give two ways to handle the requests, either by forcefully moving the request to the proper query param or to return an error. The key take-away though is where you put the code in the policy (before the await next() or after the await next()) and if your goal is to reject/return an error/secure the route you will want to make sure it’s before the await next()

Let me know if you have questions

matibaski · June 1, 2021, 12:01pm

The link “policy documentation” you put up there leads to a error 404. May you update the URL?

DMehaffy · June 1, 2021, 8:36pm