I’ve been writing a comprehensive PowerShell module that interoperates with the Octopus Deploy ReST API. Recently, I’ve added some functionality to my module that allows me to add Channel Version Rules to ChannelResource resources and save the modified ChannelResource back to Octopus Deploy.
In my organization, we have two instances of Octopus Deploy. Once’s a production instance, the other is in a development/test environment. The one in the development/test environment is a bit newer than the one in the production environment. I noticed that there were some differences in the ChannelVersionRule objects between the two server instances.
So, I thought, no problem, I’ll do what I do for vRA—I’ll include the server version information in the session object I use to safely convey API credentials between the various cmdlets making API calls to the server. I found the api/serverstatus/system-info API. Perfect. Just what I need. It has Windows Server version, .Net Framework version, and most importantly, the Octopus Server version information. Now I can capture that and my cmdlet can provide the correct data shape depending on the version of Octopus Deploy I’m working with.
One slight problem… That API—the whole /api/serverstatus API—requires Administartor-level privileges!! What?!? In particular, the /api/serverstatus/system-info API doesn’t seem to provide any particularly sensitive information. But, this API is completely unusable to me since I can’t require everyone who would use my module to be a system administrator of Octopus Deploy! And now my module cannot handle differing versions of Octopus Deploy (especially when data models change between the API calls).
Please consider how privileged (or unprivileged) a user must be in order to use a particular API–especially one concerning the Server Version, which is very general information, and important to know to even integrate/interoperate with the ReST API.
