My New Adobe Dev Ctr Article: Multi-user access for CF Admin and RDS
Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.I have a new 16-page article that was posted to the Adobe CF Developer Center yesterday:
Enabling multiple user access to the ColdFusion Administrator and RDS
If you're using CF 8 Enterprise or Developer edition, you should at least be aware of this feature. Even if it doesn't sound like something you'd need or want to use, check out at least the introductory section.
Besides explaining the features, and showing how to set them up and use them for practical solutions. It also addresses many gotchas and cautions to note, some of which may be surprises.
It shows using the multi-user admin feature for spreading out who can work on different parts of the admin (and shows enabling it even only for access to the CF 8 Server Monitor.)
And for the multi-user RDS feature, it shows leveraging it specifically within Eclipse and Dreamweaver (and points to resources for more on each and on using it with HomeSite+/CF Studio.)
I welcome comments or questions about the article here.
PS If you want to comment asking why one would use RDS due to security concerns, please read the article first. This addresses one significant concern and also points readers to additional resources to consider other concerns.
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Anyway what's with the idea of wrapping it in CFML tags? I suppose I could see how changing it to have any HTML tag in it would cause the input to be blocked on submission then, if one has CF's "global script protection" feature enabled. Is that what this is relying on?
And is the real point that you're saying one may want to somehow disable use of the root Admin username/password entirely? I'd think a simpler solution would be to change the root Admin username to something else (which requires editing the neo-security.xml file, as discussed in the article. If you're reading this and wonder, "huh? root admin username", please see the article.) Sadly, it doesn't appear that one can disable the root admin user entirely, even by editing the xml file (though I admit I've not tried deleting it entirely or setting it to the empty string.)
I needed to change the admin password to something stronger but I wanted it to be something I could remember... so I basically took the previous password and wrapped it as if it was a coldfusion variable... so <cfoutput>#myoldpassword#</cfoutput> -- because I knew I could remember that, but it was complicated enough that it was going to be hard to guess and very hard to brute force.
I wasn't *trying* to disable the root admin... just give it a better password. The disabling was inadvertent and unwelcome.
But yes, changing the username is a grand idea and I think I'll do just that.
But I suppose, if you wanted to, you *could* effectively disable it by doing as I did, setting a password that can't actually be used to log in with. Then the only way to access it is by modifying the xml file to reset the password.
I was guessing that the first pound commented out the rest in whatever properties file the data ended up in. Scriptprotect only affects script/meta/object/applet tags, so that couldn't be it. I do have a function in the application.cfm files that replaces the >< signs, but that wouldn't be inherited by CF Administrator.