Hi all, I am a Dutch IT professional who is investigating the possibilities of Dolibarr as a serious alternative for mid sized companies.
In these considerations, I am looking to more than only business functionality. Also looking into the manageability of the system (deployment and management), RBAC and the security of the data.
In the context of security, I am currently investigating whether it is possible to shield modules for use when the system is accessed from the internet.
Example of some needs:
Setup, Admin Tools, Users & Groups should never be used from the internet
Users having rights to the HRM module can access from the local network but not from the internet
Quotes for online signing are accessible to customers without further access to the system
So far, I have only managed to configure multiple virtual hosts and use the rewrite engine to impose restrictions, but this is very labor-intensive, fault sensitive and does not limit visibility in the system.
Selecting an option gives in an unclear message to to the users: “Forbidden You don’t have permission to access this resource.”
Are there other ways to approach this in Dolibarr or the underlying platform? The best would be if the unauthorized navigation elements (based on the combination of role and loaction) are not shown or grayed out.
I have thought about a 2 container kind of setup, where only container was only for all the public stuff, and the other container was for all the rest. Then the public container could have a database user which only has strictly the necessary read/write access to specific tables inside the database.
In the beginning this can surely be run with just running 2 containers with dolibarr and a shared database. Then you have one container only answer /public/ urls and also have a proxy in front that routes all the /public/ urls to this container.
This could possible be achieved using a 3. container - one container only for admin stuff. As for /user/ - then that would also mean that users can not update their own information? But I can certainly see the point with the /admin/ stuff.
HRM? that would make it hard to do Expense Reports which found under the HRM top menu, but not at all in the same URL.
MAYBE it is possible to specify which modules are enabled in each container, but I would kind of expect that this is stored in the database, so you would need to be able to tell dolibarr which configuration table in the database are used for which module.
What if you simply in these 3 containers just straight out deleted the php files you don’t need? Then it would not matter if the modules were enabled or not - the actually PHP files would be removed which is even better than “you’re not allowed to run this” then it is “run what? PHP file not found”
I was considering something like you suggest, but also want to keep in mind the managebility of the system. Multiple containers require strict administration for the application containers. Mistakes are made easy.
Also I am/was under the impression many of the configurations needed are stored in the database. Which will be shared among the app containers.
Will try to investigate this approach. A complete base setup I now can create in 2 or 3 mintes, so it is worthwhile to test a a little more next week.
Thanks for the feedback and keep you posted on my progress.
Yes, but Ansible can help a lot with the automation and with monitoring of it being deployed correctly.
yes, and this is why I both wanted to use a database user with less access rights to database tables, and also had the thought - what if you delete the PHP files you don’t need?
