Multi-user mode & UI reworks

[oskardotglobal]

This PR reworks multi-user mode, adding the concept of admins and shared plugins. It also redesignes the polling section of the recipe editor and hides the "updates" setting when running inside Docker.

The unprivileged user can now use auto-join, devices joined this way are "unassigned" and can be edited by everyone. Admins can view other people's devices.

Redesigned recipe editor for polling. The transform card shown in that screenshot is part of a serverless transform feature, which I will PR later. The settings card contains the polling-specific fields that used to be below (except bleed margin + dark mode)

Registration stays open, but users can't do anything until they are confirmed by an admin. Admins can manage users and approve/revoke them.

Plugins can be shared between users, then they can be copied to the user's account manually ("forked").

I agree to license this contribution as MIT. Supersedes #257

[bnussbau]

Hey there,

are you and @vadimitri colleagues, or are you working on this independently?

A few things to consider:

• There are too many features bundled into a single PR, which makes it difficult to review. I’d appreciate it if you could split this into multiple, smaller PRs.
• According to the survey (see Community Survey: How Are You Using LaraPaper? #47), the typical LaraPaper user is running a single-user homelab instance. While multiple users are indirectly supported through the REGISTRATION_ENABLED environment variable, the recommended setup is to keep registration disabled.
• There are also security implications. With the current architecture, user isolation is not guaranteed. Since Blade templates can execute PHP, a non-admin user could potentially access or manipulate another user’s data.
  Because of this, multi-user support, with roles and shared recipes, should be gated behind a feature flag (e.g. MULTIUSER_ENABLED env var). The security model needs to be hardened before this feature can be considered GA. Otherwise, it could create the false impression that users are properly isolated, giving a false sense of security.
• Regarding the transform feature: if you plan to implement it, I’d recommend using the transform-v2 branch as a starting point. Also keep the security and isolation of transform code in mind.

[oskardotglobal]

Hi,

@vadimitri and I are both working on this on behalf of Spark for the Spark x TRMNL hackathon next week; the two PRs just happened because of an internal communication issue. Regarding your points:

• I will split this into multiple PRs, no problem
• We can gate the Multiuser feature behind a flag without a problem, maybe even behind an "experimental" flag in the Lab settings. The security model I'm currently aiming for trusts the users a lot anyway (they have to be confirmed by an admin because they are expected to be known/trusted by an admin). Regarding the blade issue, maybe there could be a feature flag to toggle blade for non-admin users?
• We already have Python, PHP and JS transforms running in prod, using an external Go microservice (see https://github.com/spark-hpi/larapaper-serverless-runner). I'm currently working on having processes in that container namespaces using bubblewrap for extra security.

Regarding your comment in the other PR: for the hackathon, we'll be using our larapaper fork, but I think there is no reason why we couldn't contribute back the features we build. The hackathon is on July 1st, you will probably be able to find pictures on the official trmnl social media channels :)

[bnussbau]

Hey there,

appreciate the contributions, looking forward to your hackathon.

We can gate the Multiuser feature behind a flag without a problem, maybe even behind an "experimental" flag in the Lab settings.

The underlying “toggle” package supports feature flags via environment variables or database-backed UI toggles. Given the security implications, I’d prefer using an environment variable here.

Regarding the blade issue, maybe there could be a feature flag to toggle blade for non-admin users?

Ideally, it would be possible to isolate Blade execution, so that PHP code cannot be executed. If that’s not feasible, then a feature flag would be the fallback.

We already have Python, PHP and JS transforms running in prod, using an external Go microservice (see https://github.com/spark-hpi/larapaper-serverless-runner). I'm currently working on having processes in that container namespaces using bubblewrap for extra security.

That’s interesting, will check out. In this case, it would be great to implement it with an abstraction layer so that both an internal execution engine and an external serverless engine (like yours) can be supported interchangeably.