Discussion: DNN Independant Management Site with API and PowerShell

[iJungleboy]

We @ 2sic have been automating our environment for a long time now. Based on the lessons learned, I would like to propose some core challenges we will face when creating a standard solution, and how we could resolve this:

Challenge 1: Script Versions and Upgrades

I believe the core challenge to all this (aside from authentication etc.) is maintaining the level of scripting commands in a heterogeneous installation. If each installation has its own copies of scripts and capabilities, you will quickly not be able to automate across sites, because probably DNN 9.2 will be missing some of the commands added in 9.6. And adding commands will be crucial, because this is what we need when new security holes appear. So it will be important to somehow upgrade the scripting capabilities. Our solution uses a centralized scripts-server, which is accessed from each server when running scripts.

Challenge 2: Running Scripts When The Website Is Not Running

Often some changes will cause the site to not work anymore – at least temporarily. So building a solution which requires the w3-service to run will not scale as needed. Since you’re first edition is meant for local installations, this will be your initial setup – but it’s a bit the opposite of the remoting setup.

Idea To Resolve Both: A DNN independent Management API-Site

One thing I could imagine is that remoting and actually any PS-work would not happen through DNN but through a separate API/Management site, which would be necessary to use this. This would allow us to handle both challenges 1 and 2, because this admin-powershell-management-site could also manage the central library of scripts. It would also resolve a lot of other issues because authentication could be done in a custom way, and provider who don’t want this (or don’t want to give access to this to their customers) could still use it themselves.

[donker]

"Script Versions and Upgrades" Prompt supports a command "list-commands" which gives a list of all commands and their version.

"Running Scripts When The Website Is Not Running" If you go through the WebAPI then it will fire up the site.

[SkyeHoefling]

@donker I need some clarification on this WebAPI.

• Is this WebAPI locked down to just the Prompt or can anyone with the correct credentials access it?
• Is it publically exposed outside the box or is it just for localhost traffic?
• What type of authentication is used in the WebAPI?

[donker]

"Is this WebAPI locked down to just the Prompt or can anyone with the correct credentials access it?" Yes and yes. This WebAPI access point is usable by anyone who's authenticated with host credentials and can then run any Prompt command and will get the result in structured format.

"Is it publically exposed outside the box or is it just for localhost traffic?" Public

"What type of authentication is used in the WebAPI?" Regular web traffic auth. I guess this depends on how you've configured DNN but by default this is asp.net auth. This is the only part I've never programmed before, but it should be doable from what I know.

[SkyeHoefling]

This is really great news and will save us lots of work. Kudos to the team that implemented this feature! They really considered the future and how this feature will expand.

With all of that being said it makes our work so much easier. The idea from here is the powershell module will just wrap a bunch of RESTful service calls which will invoke this API. The only part that may be a bit challenging is building a auth screen into powershell.

[david-poindexter]

Hey guys, just catching up here a bit. DNN, if configured properly, supports JWT Auth. This is how I have built other solutions that are ultimately going to integrate with Prompt from the outside. So this makes it very easy in my opinion.

[david-poindexter]

Oh, and by the way, there are two endpoints in Prompt.

• One for listing commands (as @donker mentioned earlier)
• One for executing a command

Where Prompt needs some work is in the area of getting (via the API) options/params/help for individual commands. That would greatly help towards our goals here.

[donker]

Just to come back to this point "What type of authentication is used in the WebAPI?"

I just woke up slapping my forehead. The official way to WebAPI from outside of a browser (i.e. app) is of course JWT. So that is the correct answer to the question. Sorry for confusing anyone.

[david-poindexter]

Along those same lines of the JWT conversation, please see this JIRA issue I posted a while back to address this very thing. Right now there is a [ValidateAntiForgeryToken] decorator on the Cmd endpoint. From my testing, this is going to be problematic executing from the outside. Am I missing something?

[donker]

Actually it works despite the anti forgery logic. I just ran some tests with my code.

[david-poindexter]

Really? Wow - I must not be holding my mouth just right then! ;)