Server Extensibility was new to Octopus 3.5, and is still being actively evolved as we learn more about how it's being used and what customer want to extend. The documentation in this section covers the implementation as of v2.0.* of the Extensibility packages.
Forms vs External
There are two key types of Authentication Providers, those that use Forms (Basic) authentication and those that are external to Octopus Deploy. The main distinction between the two is whether the Octopus Deploy UI is responsible for collecting and username and password or whether control is passed to an external site to handle that and return a token representing the authenticated user (e.g. OpenID Connect providers).
When building extensions there are a couple of concepts that are important to know about. Path resolution is one of those things.
The reason we do it is to support a specific development scenario that we use, which involves running the server in one process (using Nancy) and hosting the UI in a separate process (Node.js with gulp watch). In this scenario, we have to distinguish between content being hosted by Node.js (using standard relative paths) and content being hosted by the extensions (which requires an absolute path based on the Nancy API location). In the deployed version, there is only one server process in play, so "/images" would resolve to the same as "images", and as such in a typical extension development scenario you wouldn't need to be concerned with using the "/".
Octopus Deploy's server UI is currently implemented using AngularJS. The UI provided by any extensions is also hosted in an Angular directive, so should you want to author your extension UI as an Angular module with directives, controllers etc you can. This is not mandatory though, you can choose to use vanilla JS if you want to.
Learn more about authoring a Forms based authentication provider.
Learn more about authoring an External provider.
In This Section
The following topics are explained further in this section: