Ruby API Class

voxxitdesigns

Verified User
Joined
Apr 9, 2005
Messages
49
For those interested, I have created a Rails plugin which allows for quick and easy interface with the DirectAdmin API. And, for the record, I hate the DA API. It really should be overhauled. :(

Download the DA Rails API plugin (Version 0.2)

For Rails versions 2.0 and above, you can install it from the command line like so:

$ script/plugin install git://github.com/voxxit/directadmin-rails-plugin.git

Otherwise, go check out the source here:

http://github.com/voxxit/directadmin-rails-plugin/tree/master
 
Last edited:
The problem, Josh, is that you've neither mentioned any specific problems or any specific solutions. It's possible that the programmers could spend weeks on it and for some reason you still wouldn't like it.

Feel free to make some positive suggestions :).

Jeff
 
Well, for one, the information isn't passed back in the best way. For example, when creating a new user using the API, the entire website is passed back, instead of one or two variables with information stating that the command was processed, and a status code. If one were to use DirectAdmin in large capacity, with the API being called constantly, this could place unnecessary strain on the server.

Here is a couple of examples of APIs that pass back information properly:

http://developer.37signals.com/basecamp/

Basecamp uses XML, which is quickly becoming the standard for APIs. It would be easier to write API classes for DirectAdmin in languages other than PHP for DirectAdmin with XML. Here's an example of a conceptual request in XML for DA:

(Let's assume that the URL request structure doesn't change..)

Request: /CMD_API_CREATE_USER

Code:
<request>
  <user>
    <username>#{username}</username>
    <email>#{email}</email>
    <password>#{password}</password>
    <password-confirmation>#{password}</password-confirmation>
    <domain>#{domain}</domain>
    <package-id>#{package}</package-id>
    <ip>#{ip}</ip>
    <notify>#{true|false}</notify>
  </user>
</request>

API should be disabled by default, and enabled only by administrators. This could possibly increase DirectAdmin's security.

On the topic of security, I believe that DirectAdmin should implement something like an "API key" that administrators have to generate inside DirectAdmin. Use the concept of Authorize.net as an example. They give you a User ID and an API key, instead of the username's actual login password. This could potentially save from their login passwords being intercepted and cracked.

Then, there are error codes that could be passed back with the XML. Instead of sending an entire web page back with some text in the middle that we have to interpret using any variety of methods in any language (e.g., "strpos($result, "Please enter your Username and Password")" in PHP), you could just build a standard list of error codes! Here is an example of Digg's error codes:

http://apidoc.digg.com/Errors#ErrorCodesandMessages

This is also useful if the language varies per user, as an error number never changes. :)

Code:
GET /CMD_API_CREATE_USER HTTP/1.1
Host: example.server.com
Accept: */*

...
HTTP/1.1 403 Forbidden
Content-Type: text/xml;charset=UTF-8
Content-Length: 71

<error code="1000" message="Cannot login without username and password" />

Let's discuss this! I am not bashing anyone, and maybe this API works for some. I just think the DirectAdmin developers should be open to making their API better, more secure, and definitely more efficient. Cheers! :)
 
For those interested, I am in the process of creating a Ruby class which allows for interface with the DirectAdmin API. I should have it for sharing within the next few days.

Cool sounds interesting :)

BTW you need to fix your site for I.E 7
 

Attachments

  • sshot-8.jpg
    sshot-8.jpg
    134 KB · Views: 358
Oh, and I think it is also important to point out that the API isn't very standardized, so it is hard to implement a standard language class for use in third-party applications. Here is an example of what I'm talking about:

Command: CMD_CHANGE_EMAIL_PASSWORD
Method: GET or POST
Success Returns: url encoded array if api is passed. Else if redirect is passed, browser will be redirected there. Else a dynamic "success" page is shown.

..versus..

Command: CMD_SELECT_USERS
Method: GET
Success Returns: Text
Failure Returns: Text

See, if DA implemented an XML method of passing information back from the server, then it could all be standardized.
 
Well, for one, the information isn't passed back in the best way. For example, when creating a new user using the API, the entire website is passed back, instead of one or two variables with information stating that the command was processed, and a status code. If one were to use DirectAdmin in large capacity, with the API being called constantly, this could place unnecessary strain on the server.
Then you're using the wrong command. It should start with CMD_API, eg:
http://www.directadmin.com/features.php?id=167

API should be disabled by default, and enabled only by administrators. This could possibly increase DirectAdmin's security.
I'm not sure I agree with this. The API uses the exact same code as the rest of the features in DA uses. If you only have a User account (and not an Admin account) then you can only call User level API commands anyway. There is no security issue in my mind since the things they can do in the API are the exact same things they can do in the interface.. they need password no matter what. Plus the *exact* same internal code is used to process it. The only different is the output, CMD_API commands are nice and parseable.

On the topic of security, I believe that DirectAdmin should implement something like an "API key" that administrators have to generate inside DirectAdmin. Use the concept of Authorize.net as an example. They give you a User ID and an API key, instead of the username's actual login password. This could potentially save from their login passwords being intercepted and cracked.
I would not disagree with this. Having plaintext password makes it harder to hide. Note that we do have session keys already, to be used by plugins/skins, so they can use the API without a password.
http://www.directadmin.com/features.php?id=362

Command: CMD_SELECT_USERS
Method: GET
Success Returns: Text
Failure Returns: Text
Use the CMD_API version instead ;)

CMD_API_SELECT_USERS (was added a few versions ago, in case you are using an older version of DA)

John
 
Hey John,

Thanks for the feedback.

Then you're using the wrong command. It should start with CMD_API, eg:

That's fine. What I'm saying is that:

#1 - There are no standard error codes. This should be something that is implemented within DA so that the need to transmit back error messages is not as important. Also, instead of searching for a string of text in a response, we can search for an error number in a place where we know it is, and know exactly what it means. (See: http://services.digg.com/errors?appkey=http://apidoc.digg.com)

#2 - I think it would be much more useful to pass back information in XML format, as more and more languages make it much easier to parse XML data than to parse URL-type encoded strings. Notice how I am not stating a specific language, as your software should support open formats, not just PHP. -:)

#3 - Maybe we could get rid of the information on the _API_ page about non-API formats? (e.g., CMD_SELECT_USERS?) Or, you could just put it on another page all together. That would be much more helpful.
 
Hi John

I fully agree with you in the fact that the API from a consumption point of view is horrible. DA does have a valid point on the security, but I fully understand where you're coming from.

To the DA guys, REST is becoming the defacto means for exposing API's, just look at Amazon's Web Services and other big players. Having a REST API would simplify the use of the API and make it friendlier to ANY programming language since everyone has either XML libraries, and possibly REST libraries available. The current API screams of PHP influences.

Then back to John, how's the Ruby lib going? Don't want to duplicate too much effort on my side. Can you publish it on Github?
 
The current API screams of PHP influences.
What does that mean? Sounds cool, but give us example please :)

I'd agree that the API is cumbersome, but I'm willing to bet the DA guys are well aware of what REST is and who uses it, and are currently just exposing a more native format the DA server uses internally so we can hook into it.

I do like Voxxit's suggestions for a later version. Being able to check a common response variable to see if the request was successful would be helpful along with a standard response structure. XML would be convenient to parse too.
 
Last edited:
Just a quick update for everyone!

I am in the process of actually creating a Ruby on Rails Plugin for interfacing with DirectAdmin, since most people use this app for billing, etc. these days with the Ruby language (including me!)

You can track the progress of my development here:

http://github.com/voxxit/directadmin-rails-plugin/tree/master

Please keep in mind that I am at the VERY early stages of development of this plugin. So far, I am able to send GET and POST requests to the server. I have only really tested GET requests, and tonight I am going to test POST requests (e.g., creating a new user, etc.)

Note to DA: this would be a LOT easier if we could get XML implemented into the API, FYI.
 
POST worked successfully! Now, I just need some feedback. Here is a sample response from using the command CMD_API_ACCOUNT_USER:

error=0&text=User sampleuser created&details=<br> Unix User created successfully<br> <br> User's System Quotas set<br> User's data directory created successfully<br> Domains directory created successfully<br> Domains directory created successfully in user's home<br> <br> <br> <br> Domain Created Successfully<br> <br> User added to ssh config file.<br> <br>

Would you rather:

A.) Have the plug-in decode the response from the server for you, and put it into an array? Or,

B.) Do this yourselves in the controllers of Rails?

I ask because the process of figuring out which API calls do what may make the script a bit garbled. I am going to see what the other API classes do to get a feel, but I'd rather do what the users of DA would want me to do.
 
Has anyone been able to get CMD_API_SHOW_USER_DOMAINS with this API?

Seems like it only supports POST not GET. I can't figure it out for the life of me.
 
Back
Top