Allow for config parameters to be used for auth tokens

[ojintoad]

Expected Behavior

We currently have powershell scripts that call services using a TeamCity configuration parameter for authentication. Yes, it is unencrypted, but it is secure enough (via permissioning) as a "password" type configuration parameter. I would like to have the webhook template auth configuration use this same parameter.

Current Behavior

The webhook template auth configuration doesn't seem to respect this parameter. %paramname% and ${paramnane} do not seem to work.

Your Environment

• tcWebHooks Version: 1.1-alpha16.223.329
• TeamCity Version: TeamCity Enterprise 2018.1 (build 58245)
• TeamCity server Operating System: Windows
• Are you using a WebHook Template?: Yes

[netwolfuk]

Yes. You're right. It does not use the variables from the payload.

It feels like a it's a useful feature but be aware that will leak your credentials if you use the legacy payloads, because on the legacy payloads all these variables are included in the webhook body.

Update: just to clarify. Auth credentials themselves will never be included in the payload body, but if we implement this feature, and payload variables are used for auth credentials, then they would be visible when using the legacy JSON and XML formats (but not Tailored-JSON or Empty formats).

[ojintoad]

I've already observed that yeah. Thank you though - good flag for anyone else reading this. We've already moved away from the legacy payloads though, the templates are way better.

We do plan on moving to a situation where we'll have tcWebhooks post to an intermediary that will then communicate with the actual service we want to trigger, so the actual service's auth won't be directly exposed (though our intermediary would be, but that'll further limit what sort of things someone could mess with)

[netwolfuk]

I'm starting to like this idea BTW. I'll have a look into the code and see how easy it is to inject the resolver into the auth code.

Thanks for the feedback that templates are better. I was hoping that would be the case.

[netwolfuk]

I had a look at this and it's quite a large refactor to make the resolver available to the authentication factory.

I will make this as milestone 1.2 as I am on the last story for 1.1 release and don't want to delay that further.

[netwolfuk]

BTW, I just remembered that the header support does support variable resolution.

So if you want to craft an Authorization header using header support, you could do that until I get to add variable resolution to the authenticator in the 1.2 version.