Skip to content
This repository has been archived by the owner on Jan 17, 2024. It is now read-only.

Custom Service Endpoint #30

Closed
mmajcica opened this issue Mar 3, 2016 · 6 comments
Closed

Custom Service Endpoint #30

mmajcica opened this issue Mar 3, 2016 · 6 comments

Comments

@mmajcica
Copy link

mmajcica commented Mar 3, 2016

Hi,
is it possible to create a custom service endpoint type as you have done for Azure, Jenikins, etc.
If so, could you point me to an example code? Also could we ship this new endpoint type via the extension?

Thanks
Mario

@omeshp
Copy link

omeshp commented Mar 7, 2016

yes you can create a custom service endpoint using extensions. To do that you will need to add a new contribution that targets ms.vss-endpoint.endpoint-types. Here is an example of chef endpoint type contribution that uses basic authentication:

"contributions": [
  {
    "id": "custom-chef-endpoint-type",
    "description": "Service Endpoint type for all Chef connections",
    "type": "ms.vss-endpoint.service-endpoint-type",
    "targets": [ "ms.vss-endpoint.endpoint-types" ],
    "properties": {
      "name": "customchef",
      "displayName": "Custom Chef",
      "authenticationSchemes": [
        {
          "type": "ms.vss-endpoint.endpoint-auth-scheme-basic",
          "inputDescriptors": [
            {
              "id": "username",
              "name": "Node Name (Username)",
              "description": "Chef username",
              "inputMode": "textbox",
              "isConfidential": false,
              "validation": {
                "isRequired": true,
                "dataType": "string"
              }
            },
            {
              "id": "password",
              "name": "Client Key",
              "description": "Client key specified in the .pem file",
              "inputMode": "textarea",
              "isConfidential": false,
              "validation": {
                "isRequired": true,
                "dataType": "string"
              }
            }
          ]
        }
      ],
      "helpMarkDown": "Learn More"
    }
  }
]

@omeshp
Copy link

omeshp commented Mar 7, 2016

For token based authentication, the autheticationSchemes field will look like:

"authenticationSchemes": [
  {
    "type": "ms.vss-endpoint.endpoint-auth-scheme-token",
    "inputDescriptors": [
      {
        "id": "apitoken",
        "name": "API Key",
        "description": "API key for connection",
        "inputMode": "textbox",
        "isConfidential": false,
        "validation": {
          "isRequired": true,
          "dataType": "string"
        }
      }
    ],
    "headers": [
      {
        "name": "Authorization",
        "value": "api_key {{endpoint.apitoken}}"
      }
    ]
  }
]

@mmajcica
Copy link
Author

mmajcica commented Mar 7, 2016

Thank you very much!
That's precisely what I was searching, although I thought it may be that I should somewhere implement ITaskEndpoint interface. The dictionary that this interface exposes, called Data, contains all of the information about the username and password. The password is however passed as a string. Is there a way to have it persisted as a SecureString?

What does isConfidential property on inputDescriptors do?
For the validation, what sort of dataType's do we have at our disposition?

I'll jump right away on it and check how it works.
Mario

@omeshp
Copy link

omeshp commented Mar 7, 2016

Hi Mario,

All the authentication data belonging to an endpoint(i.e all the fields belonging to authentication scheme) are encrypted and persisted using strongbox service. In memory they are represented as strings, values for which are fetched and unencrypted only when required.

isConfidential false means that input will be visible after typing, if you set it to true that we will mask the input using ******.

For different dataTypes have a look at https://www.visualstudio.com/en-us/integrate/extensions/reference/client/api/vss/common/contracts/forminput/inputdatatype

@mmajcica
Copy link
Author

mmajcica commented Mar 7, 2016

Thank you for the detailed answers!

@JoshuaTheMiller
Copy link

In case folks come across this Issue first, another Issue exists that discusses consuming Service Connections in a TypeScript extension: #135

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants