Skip to content

Latest commit

 

History

History
239 lines (186 loc) · 8.09 KB

FINDINGS.adoc

File metadata and controls

239 lines (186 loc) · 8.09 KB

Directus poc (proof of concept), wip

Table of Contents

Installation

Dependencies

Build

nvm install 18
nvm use 18
pnpm install
pnpm build

For convenience set version 18 as the default:

nvm alias default 18

Create database

psql

postgres=# create user directus with password 'admin2k';
CREATE ROLE
postgres=# create database directus owner directus;
postgres=# grant all privileges on database directus  to  directus;

Setup .env file (already in poc branch)

In api/.env:

HOST="0.0.0.0"
PORT=8055

DB_CLIENT="pg"
DB_HOST="localhost"
DB_PORT=5432
DB_DATABASE=directus
DB_USER=directus
DB_PASSWORD=admin2k

KEY=admin
SECRET=admin2k

ADMIN_EMAIL[email protected]
ADMIN_PASSWORD=admin2k

Bootstrap database

pnpm --filter api cli bootstrap

Configuring SSO

Create a client in the sso server to be used by directus:

  • Login the admin interface

  • Choose realm vpro-azure

  • Go to clients

  • Create client with the following settings:

Save client and copy the client secret from the credentials tab. Put this and the following settings in the api/.env file

AUTH_KEYCLOAK_DRIVER="openid"
AUTH_KEYCLOAK_CLIENT_ID="directus"
AUTH_KEYCLOAK_CLIENT_SECRET="FILLMEIN"
AUTH_KEYCLOAK_ISSUER_URL="https://sso-test.vpro.nl/auth/realms/vpro-azure/.well-known/openid-configuration"
AUTH_KEYCLOAK_IDENTIFIER_KEY="email"
AUTH_KEYCLOAK_ALLOW_PUBLIC_REGISTRATION=true
AUTH_PROVIDERS: 'keycloak'

To remove the login for the default provider from the login screen set the following in api/.env:

AUTH_DISABLE_DEFAULT=true

But only do so if you already given a user from keycloak admin rights in Directus.

Running

Documentation says you can do it with:

pnpm --recursive dev

But with a race-condition caveat.

So run it (in two shells) with:

pnpm --filter api dev
pnpm --filter app dev

This wil run the api at 8055 (as defined in .env) The admin interface will run at 8080, Link

Findings

Security

Security is role based with flexible permissions

Roles

Roles from keycloak are not automatically associated in Directus: directus#18131 directus#16812 directus#11306 So a plugin must be used leveraging an event action on auth.create and auth.update See https://docs.directus.io/extensions/hooks.html It is possible to automatically assing an existing role to a user in the .env file ie:

AUTH_KEYCLOAK_DEFAULT_ROLE_ID=Editor

Permissions

Users only have one role, there are no groups. If wanting to use groups it would need to be implemented. For instance a 'groups' field and create custom permissions based on that? Leverage the code in this role-switcher for that: https://github.com/u12206050/directus-extension-role-chooser

There is talk about business rules on https://docs.directus.io/user-guide/user-management/users-roles-permissions.html However no hints there on how to implement that. Found information in the Workflow doc how you can set permissions to use fields in collection to restrict actions through custom permissions. https://docs.directus.io/user-guide/user-management/permissions.html#configure-custom-permissions

Multi tenancy

Multi-tenant is not implemented. Several discussions about this: directus#3987 directus#9682 directus#2687

Other solution offered is to go multiproject, so every group gets its own database/instance. This requires more work with regard to settings migration. For the data model there is this: https://docs.directus.io/guides/migration/ For the security configuration there is no real solution, other then build your own on the api. See directus#9542 However going multi-project would simplify permissions but due to the number of instances it would still require custom tooling to manage all this.

Workflow

The suggestion has been made to filter this on the api side, but that is insufficient for us. It would be better to leverage the custom permissions on the role used by the frontend (Public) to restrict access.

Images / Assets

Assets are called Files in Directus. They are quite simple and don’t support much in the way of metadata. They do support multiple storage drivers so storing it in s3 is easy. Several storage drivers are supported.

For the metadata the solution would be to create a separate collection to maintain those, which is quite easy. However the relation between the metadata and actual image is not enforced so there will be difficulty maintain correctness.

Another option would be to modify the directus_files model. However the impact of doing that is a bit unclear. A short test revealed that a required field is not checked, so empty metadata would still be a problem.

One could also store images mostly outside of directus, in Cloudinary, see https://medium.com/birdie-ai/how-to-manage-your-content-with-directus-and-cloudinary-ded6ddd9a4b1 for how to do that. That works by creating a custom datatype.

For more discussion around this: directus#7612 directus#14742

Sloppy: By default nobody has read access to the uploaded files so images won’t render if you embed them in richtext.

Richtext

Richtext is quite configurable most features can be enabled/disabled. There is however no way to link to other collections in the richtext. Links are always full urls. Storage is as html and images are stored as a complete img tag.

Data migration

I concocted a simple script to import the 3voor12 data. See python script. It imported all nearly 30 thousand items in about 10 minutes. Just the most basic fields, but in a quite straightforward manner.

Extensibility

Directus seems to be very extensible. Let’s try something here:

nvm use 18
npm init directus-extension@latest

Interesting extra features

  • Dashboarding

  • An active community (e.g. on discord)

  • Schema migration

Conclusion

  • It is tightly coupled to a relational database.

    • We like to be able to deal with large amounts of data, which should be no problem for something like postgresql.

  • It can be obtained hosted and self-hosted. Self-hosting is not difficult.

  • Importing data is simple.

  • Using the api is easy. It’s quite forgiving. E.g. I could just use the original uuids as id’s and it worked.

  • SSO authentication works, with some limitations

  • Documentation is somewhat lacking, but the code is clear.

  • The security model is limited

  • Worfklow/Embargo must be implemented by us.

  • For multilingual content something like this could be done: https://medium.com/directus/multilingual-content-setup-in-directus-i18n-4f243f72e554

  • Multi-tenancy is not supported out-of-the box. Multi-project is the only solution to this without loads of work.

  • Assets are supported but will require extra metadata models

  • External asset management will require building extensions.

  • Richtext is just html, no references to other collections are possible other then through the encompassing model.