Consider the following situations …
* You don’t have access to the ColdFusion Administration, but need to make simple changes (like registering your IP addresses for debugging).
* You need temporary datasources (perhaps for data import tasks) and want to be able to programmatically create (and drop) them.
* You automate user account creation processes (FTP, e-mail, and more), and need to define ColdFusion Administrator settings for new users.
* You are the administrator, and want to allow users to be able to set specific Administrator settings only without granting them ColdFusion Administrator access.
You get the basic idea. The ColdFusion Administrator is a bit of an all-or-nothing proposition, and that is not changing in Blackstone. What we are planning on changing is providing developers with an alternative to the ColdFusion Administrator, and Administration API.
I am not going to comment yet on exactly how the API is implemented (or what the calling code looks like). But I do want to comment on the API itself, and the problem it addresses.
The intent is to provide a series of calls that will provide access to settings in the ColdFusion Administrator, both getting and setting. From reading current server settings, to changing debug settings, to defining datasources, to registering CFX tags, to … lots of stuff.
Now before anyone panics, this does not mean that anyone who can write CF code can make ColdFusion Administrator changes. The APIs will require that a password be specified, and it is unlikely that all developers would be given that password (if they had it they’d be able to use the ColdFusion Administrator now). Rather, the API will be used by administrators to create custom consoles, mini-admin applications, and scripts. Administrators will use the APIs to allow developers to self-manage (to the extent that they allow).
So, if you need to create datasources the administrator could whip up a “create a datasource” screen. And if you needed to register a debug IP address, a simple script could do that. And so on.
I’ll post more details in the future.
Understanding Blackstone's Administration API
15 responses to “Understanding Blackstone's Administration API”
-
I’m all for API’s but what would be better is the ability to have multiple log-ins to the admin console with different levels of "user rights". I hate having one password for the system that has to be shared throughout the organization.
-
Hi Ben,
will it be possible to mix this Admin API with a BS gateway? -
Not wishing to speak for Ben but…
João, since you will be able to call the Admin API from ColdFusion code, yes, you would be able to write a gateway CFC that interacted with the Admin API… which means that you could indeed write a CFC to allow you to administer a CF server via a cell phone using SMS, for example. -
How his this different from the not-so public admin cfc API found in cfmx6.1 ?
-
Eric, we used to have some of that in CF4, and no one used it.
João, as Sean said, yep.
Ivo, very different. For starters, it is documented. It is also secured. And it is also not as low level. All around much better. -
Eric,
We can now write an application that extends CF’s admin API and allows us to have different levels of ‘user rights’, if I’m understanding this correctly.
Calvin -
Calvin, that is correct. You now have the control to do whatever you want.
-
how do you restrict access to the API, eg on shared hosts?
-
Barry, the admin API needs a passed password. If an ISP or hosting company creates their own console then they can create any security front end. Again, developers would not likely have full access to the admin API, it is more likely that admins will create their own consoles or scripts using this API.
-
so the password has to get passed as an argument whenever a method from the API is called?
-
Barry, yes, the admin API cannot be used without a password, allowing that would be a bad thing.
-
I agree that securing the API with a password is a good idea, but I must say that putting plain text passwords inside templates isn’t.
It would be good if the admin API could (as an alternative) be enabled by a sandbox rule, just as datasources can be enabled by sandboxing. -
James, I would expect that any custom admin console that is built and deployed to a server would be deployed in a sourceless manner for extra security…
-
Of course, I keep forgetting that we (should) get sourceless distribution in Blackstone. I think that would be secure enough for most applications – if a hacker can compromise a system badly enough to get the compiled source and reverse engineer it they are in a position to do far more damage than just write a few admin console routines…
-
re: sourceless deploy of admin console.
yes, that makes sence for security reasons. I’m not privvy to what’ll be in blackstone but I’d guess that sourceless deployment wouldn’t be available for standard cf7 – at least that would make sence (for marketing only).
if so, we’re stuck – our customers running our apps won’t cough for the 6.1(STD) to 7(ENT) upgrade just because we want to deploy our apps without the source code. if that’s the case, we’d be mad to create an admin console for them.
this admin feature sounds like it’d really be targeted only to webhosts – and no one else.
Leave a Reply