I’m looking for a way to protect a special User Account from being deleted.
For context: I’m working on a collaboration app that amongst other things creates shares for in app objects and shares them with assigned users and groups. I opted to create a dedicated user as owner of everything instead of building my own storage solution. I know, groupfolders does almost the same thing, but for several reasons I don’t want to rely on groupfolders and I don’t want the share to be owned by the user creating the related app object.
This however would breaks my whole app if this dedicated user is deleted.
I tried to utilize the EventDispatcher and registered a lot of EventHandlers for e.g. the BeforeUserDeletedEvent, … and stop propagation, but I would have to consume all other subsequent Events like UserDeletedFilesCleanupListener as well or throw a serious Exception to stop deletion. So this is clearly not the way to go, …
Does someone have an idea how to prevent the deletion or protect the user as long as the app is enabled? Or is there something like a dummy user I haven’t found yet i could use?
You did not describe your use case in detail, so it might be not accurately matching whatever I am writing.
In general, you identified the solution to go, yet: create your own storage interface.
It might be possible to use e.g. the app storage and a set of DB tables to establish the storage backend…
Otherwise, your app will always be depending on the existence of a certain user.
This can be done in a completely jank-free way:
You need to implement your own user backend and possibly if the users needs group memberships your own group backend. That makes your app completely in control of users from that backend and you can just not implement user deletion or if that is not a valid user backend implement it so it simply errors-out when somebody tries to delete the user.
The users from your backend will still show up in all the places users show up (users page, shares, …), because those aggregate from all user backends and the userId will be valid, but it the user is not even stored in the nextcloud user database, so it cannot even be deleted there.
For reference see the user backend of the user_saml app (that is how they get to store the saml users in the oc_user_saml_users database table, not the nextcloud core user table): https://github.com/nextcloud/user_saml/blob/master/lib/UserBackend.php.
Other authentication related apps probably have user backends too, if you need more examples.
1 Like