Developer license for creating a plugin

staging4hosters

Verified User
Joined
Jul 20, 2019
Messages
12
Hi there,

we would like to create a Directadmin plugin for our platform. We currently only have one for cPanel and several custom solutions (done by our clients).

We would like to know if there is such thing as "Developer license" like cPanel or WHMCS offer.

Is it expected to pay the full price of the license for this purposes (it will only host test sites)? That is not a huge problem, just wondering if we could save or reduce that cost ($348/year). Normally we keep the server alive for automated testing and updates (it is not that we kill the server after the plugin has been published).

We have looked at the personal license ($24/year), but from what I have read we could only have one admin account and is somewhat special.
If this admin account behaves like a regular user when login into the website management section that wouldn't be a problem - but we need to make sure that it works OK for a regular user.

We know that the "partner" price is $5/month from our clients but we don't know where to get that price for a license (they aren't allowed to sell us those licenses because our server doesn't run in their infrastructure).

We have found some "license resellers" that offer that price but somehow look phishy (they don't offer paypal or stripe, for instance).

What would be the best way to go forward here?

Thank you for your help.
 

smtalk

Administrator
Staff member
Joined
Aug 22, 2006
Messages
9,543
Location
LT, EU
"Personal" should have no issues, as it has has full "user-level" functionality.
 

staging4hosters

Verified User
Joined
Jul 20, 2019
Messages
12
Hello,

It took a while until we have been able to start with this.

So we have bought a personal license but when we log as the user, the API requests using
Code:
$sock->set_login(getenv('USERNAME'));
No longer work, we do have to add the password:
Code:
$sock->set_login(getenv('USERNAME'),'adminpassword');

Then it works again.

Is this because the user is 'admin' and with user admin that auth method does not work?

If yes, Is there an alternative way of executing commands on behalf of the user without passing the password that would work for all kinds of users?

Thank you, best
 

staging4hosters

Verified User
Joined
Jul 20, 2019
Messages
12
Hi,
thank you for your reply.

Yes, I have already read that - but if we make a distributable plugin, are we supposed to ask the directadmin owners to enter their admin password somewhere in the plugin configuration?
That would be less than ideal. How do other plugins solve this?

Again, the question is: is this because it is an admin? I remember when we had a trial license (normal) with multiple users, the password was not required at all if we wanted to execute API commands on behalf of the user.
Code:
$sock->set_login(getenv('USERNAME');
worked just fine.

If this is the reason, then we will have to create somehow different versions of the plugin, if it is for a personal license, then ask for the password, if not, then not needed. Does this make sense?

Thank you again
 

smtalk

Administrator
Staff member
Joined
Aug 22, 2006
Messages
9,543
Location
LT, EU
Yes, I have already read that - but if we make a distributable plugin, are we supposed to ask the directadmin owners to enter their admin password somewhere in the plugin configuration?
I'm not sure why do you need to login there, if you're already logged in to DA? (I mean plugin is running there, session is also there, why do you need to login again?)
 

staging4hosters

Verified User
Joined
Jul 20, 2019
Messages
12
This is how I understood that the PHP SDK works, according to the examples here (all examples do set_login):
- https://forum.directadmin.com/threads/php-class-for-communicating-with-da.258/
- http://files.directadmin.com/services/all/httpsocket/examples/

I have tried executing commands without doing
Code:
$sock->set_login();
and they don't work.

Also just found a similar discussion here - apparently unresolved for the admin user (to have the plugin execute some admin level API queries).

In my case the login_keys solves the problem up to a certain point. As it is stated in that thread, if I put the admin login key in a file in the plugin path, how can I hide it from the users potentially finding it? Can I pass custom environment variables to the plugin that are protected from regular users?

Is there an alternative way of achieving this? Maybe having some plugin configuration table in the database accessible by the plugin?

Thanks, best
 

youds

Verified User
Joined
Jul 11, 2008
Messages
424
Location
Lancashire, UK
I’ve yet to see an answer to this. I think, with the session of DirectAdmin opened, you are supposed to file_get_contents the DA URL with API calls made to varying areas. I fell back onto a iframe call to retrieve my data, using this notion. I’m sure here is an easy way but yes, with the DA PHP API scripts it seems rather lame.

Note, you get the admin password when plugin is installed.
 

staging4hosters

Verified User
Joined
Jul 20, 2019
Messages
12
I think I have a better understanding now of how the plugins work, and I also found other resources that may explain why/how the authentication system has been thought of:
- https://docs.directadmin.com/directadmin/customizing-workflow/writing-a-plugin/
- https://help.directadmin.com/item.php?id=294
From this last link:
4) Plugins

Plugins are scripts which you create, allowing you to let your Users to do tasks, but only with the process level of their own user ID*.
The main benefit of plugins is their ability to be installed with 1 click, work on any OS, any Skin, without needing to do any other modifications to your setup. They're also "safe" in the sense that the calls made by a plugin run only as the User, and not root.

*You can get root access with a plugin if you create a plugin binary with chmod 4755, but can be a huge security risk if done incorrectly, so not usually recommended unless you're completely confident in your security-coding abilities.
Then the recommended way to have plugins execute admin/root tasks is by creating a wrapper as described here:

Then we have the new login keys, which would allow to create a key and put it instead of the admin password (as it can be restricted in scope).

So the security problem I see with plugin authentication is that every user has access to the files in the plugin tree
Code:
/usr/local/directadmin/plugins/myplugin
, so there you cannot include any credentials, as they can potentially be found and abused.
With this in mind it makes sense to just use the USERNAME for auth, but you can't safely achieve many tasks using a plugin executed as a user.

The solution for this would be to have those task being executed by the admin plugin or do some workarounds with cron like this:

Note, you get the admin password when plugin is installed.
I didn't know that, thank you. Maybe can be used to e.g. set up the cronjob.
 
Top