skyehoefling / dnn-powershell

A DNN Powershell Module

Skye (she/her)

Hello 👋

My name is Skye and I am a Senior Software Engineer II @ Blizzard Entertainment working on Diablo IV
I used to make open source software

🎮 Gaming 📱 Mobile 💻 Cross-Platform

Languages

                 

Gaming

 

Platforms

       

UI Toolkits

     

IDEs

           

dnn-powershell's Issues

Interacting with the Prompt WebAPI

I created the following code to show how you can access the WebAPI through JWT. This should be the basis for the code we'll create.

    class Program
    {
        static void Main(string[] args)
        {
            var scheme = "http";
            var host = "localhost/path/to/site";
            var uname = "host";
            var pass = "dnnhost";
            var url = string.Format("{0}://{1}/DesktopModules/JwtAuth/API/mobile/login", scheme, host);
            var request = WebRequest.Create(url);
            request.ContentType = "application/json; charset=utf-8";
            request.Method = WebRequestMethods.Http.Post;
            using (var streamWriter = new StreamWriter(request.GetRequestStream()))
            {
                string json = "{\"u\":\"" + uname + "\"," +
                              "\"p\":\"" + pass + "\"}";

                streamWriter.Write(json);
                streamWriter.Flush();
                streamWriter.Close();
            }
            string text;
            var response = (HttpWebResponse)request.GetResponse();
            using (var sr = new StreamReader(response.GetResponseStream()))
            {
                text = sr.ReadToEnd();
            }
            var outfile = string.Format("D:\\Documents\\Visual Studio\\Projects\\JwtTest\\{0:HHmmss}.json", DateTime.Now);
            using (var sw = new StreamWriter(outfile, false))
            {
                sw.WriteLine(text);
                sw.Flush();
            }


            var token = Newtonsoft.Json.JsonConvert.DeserializeObject<Jwt>(text);
            var promptUrl = string.Format("{0}://{1}/API/PersonaBar/Command/Cmd", scheme, host);
            request = WebRequest.Create(promptUrl);
            request.ContentType = "application/json; charset=utf-8";
            request.Method = WebRequestMethods.Http.Post;
            request.Headers.Add("Authorization", "Bearer " + token.accessToken);
            using (var streamWriter = new StreamWriter(request.GetRequestStream()))
            {
                string json = "{\"cmdLine\":\"list-commands\"," +
                              "\"currentPage\":\"20\"}";

                streamWriter.Write(json);
                streamWriter.Flush();
                streamWriter.Close();
            }
            response = (HttpWebResponse)request.GetResponse();
            using (var sr = new StreamReader(response.GetResponseStream()))
            {
                text = sr.ReadToEnd();
            }
            outfile = string.Format("D:\\Documents\\Visual Studio\\Projects\\JwtTest\\{0:HHmmss}-prompt.json", DateTime.Now);
            using (var sw = new StreamWriter(outfile, false))
            {
                sw.WriteLine(text);
                sw.Flush();
            }

        }
    }

The token is simply this:

    public class Jwt
    {
        public int userId { get; set; }
        public string displayName { get; set; }
        public string accessToken { get; set; }
        public string renewalToken { get; set; }
    }

Note you need to enable JWT and if you're running locally over http (not https) then you need to adjust the web.config to allow for this.

Balance between library and ps code

From my earlier PS work I veered between doing stuff in .net in a dll and using ps scripts for other commands. Any preference here? Here are IMHO pros and cons (from which you can deduce my preference):

Pros of C# dll over PS:

• Easier to read and code
• I'm not sure but I think you can do more (I wouldn't know how to do proper OOP in PS)
• Better version control from our side. It will be immediately obvious which version of this tool is being used by someone from the version nr on the dll.
• Can easily be tweaked to also work for other technologies

Cons:

• Harder to tweak for end users (you need to recompile and then to restart PS to reload the library)

Discussion: DNN Independant Management Site with API and PowerShell

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.

PowerShell or CLI?

A few things I have been tossing around in my head that needs to be flushed out is the direction of this utility. Should the utility be a

• Command Line Interface (CLI) that can be run cross-platform
  or
• PowerShell Module Windows Only
  or
• PowerShell Module Cross Platform

Out of those 3 options I don't think we should consider Windows Only because that limits administration environments. DNN is built on the .NET Framework which needs to be hosted on a windows machine but that user could very well be executing from Windows Subsystem for Linux (WSL). This opens up several use cases for automation and leveraging other scripting languages and utilities that are not available on Windows.

This leaves us with really 2 main options

• PowerShell
  or
• Cross Platform CLI

Build a cross-platform PowerShell is easy enough but there are some limitations with this that should be discussed.

• What version of PowerShell do we want to support?
• Are there certain features of PowerShell that we want to leverage that may not be available in PowerShell Core vs PowerShell for Windows
• Using PowerShell enables us to easily distribute on the PowerShell Module Repository

Building a Cross Platform CLI also opens up a different series of questions and problems that we will have to over come.

• Using a CLI we would need to distribute via a curl script or something similar to download the necessary files
• Creating a CLI with dotnet core gives us the power to use C#
• Creating a CLI does mean we need to build the interface or pull in a package that scaffolds a CLI for us

When decided what to use we have a few things to consider.

• How will the interface communicate with DNN?
  • Will there be a service call?
  • Will the interface communicate directly with DNN assemblies being executed from the same machine?

These are just thoughts that I want to use for discussion. I am not 100% sure what the community wants most, but I strongly believe we should do everything in our power to make this cross-platform.

Data

As I've stated elsewhere I think the real power will come from being able to script multiple sites at once. For that we need to be able to keep a list of the user's sites and his/her jwt token (we don't need to store passwords) for that site.

My plan (and I've begun work on that in the PR #6 is that this is a json file next to the dll. The json file stores the sites with (a) a key, (b) a url and (c) the token. I plan to encrypt the token for security using SecureString. The key is used by the user to refer to that site (instead of having to hammer out the url every time he/she wants to run a command).

Initial Scope Discussion

This is an email discussion that got started today with Peter Donker, Daniel Mettler, Kelly Ford, David Poindexter, Clint Patterson and Andrew Hoefling. The discussion have been copied and pasted into this issue to make the communication open for anyone to participate in.

Hoefling Software Mail - DNN Prompt and MS Powershell.pdf

The purpose of this issue is to discuss MVP goals and to start coming up with tangible items to put into the MVP document.