I run an ISPconfig instance for some students and it is working really well, I have API that create users, website and database. As everything is setup for them, I'm wanting to restrict access to certain settings for the users own good. I have tried this with a custom theme, but I'm not really sure where to start with the templating system. I could likely get away with just hiding elements but I'm struggling to find #id's to target specific elements. I'm just wanting to give them a system that has what they need i.e. database management, access to site backup, change PHP versions. I don't want them removing the shell user, or messing with the domain they are assigned. Could anyone give me a pointer on where I could look to start developing this more restricted theme? Thanks in advance
I think you are trying the hard ways, as to me from what you described, you don't even need to give them access to ISPConfig interface at all, just phpmyadmin, ftp and ssh, except that won't allow them to control php version and download backup to their site's backup folder, so api for that only should suffice?
I don't know about the theming, but the two concerns you mention are addressed directly in ispconfig already. I presume each student is given their own 'client' to login with; if you as the admin create the website and shell user, they as the client won't be able to edit it remove them, as long as you have 'Client protection' enabled in main config.
@ahrasis - the self service element is still pretty handy. Website backup is a bit of an opt in feature to conserve disk space so requires a bit of interaction on the admin pages. Thanks for the suggestion though. @Jesse Norell - I do have client protection enabled but this still seems to allow me to delete the website and shell user associated with the a student account. I'll have a bit more of a play with this feature to make sure it is configured correctly. Thanks for the pointer there.
Theming is the wrong way to implement such protection, in my opinion as it would allow the user to easily skip the protection and it's way more work that what would be needed to achieve the intended protection. What you should do instead, and what's way easier to implement as it just needs a few lines of code, is to write a small interface plugin that binds to the onBeforeUpdate and onBeforeDelete events of the items that you like to protect and the code in this function consists just of a 'if not admin, show alert that the current user is not permitted to alter or delete this record.
@till - I totally see your point here about doing this in a safe way, the students are a little older and less likely to intensionally use hacky tricks to do anything. I'll take a look in to the bind events you mentioned, I'm not exactly a PHP coder but I might be able to do something here. Thanks for your help.
Have a look at the folder /usr/local/ispconfig/interface/plugins/ to get an idea how this works. And just one hint, the plugins get loaded at login, so whenever you like to add a new plugin, log out and log in again to 'activate your new plugin.
I am a little older and will quite happily use a hacky trick to work around something.. Just take a look at some of my posts here you will see what I mean haha. My point here, obscurity is not security.