UCCX does not natively protect HTTP Triggers.
I wanted to come up with a solution to handle HTTP cookie based authentication.
There is a zip file for this project attached to this article. It was written on UCCX 12.5(1).
What a coincidence, sitting here updating my rudimentary http trigger application for prompt management capabilities using a similar process as you've outlined here. The challenge I'm running into is there doesn't seem to be a way to assign API access to agents or supervisors, so although I can authenticate them via the http trigger and use their login info (for auditing purposes) to upload the new prompt, I've had to either embed the API user info in the script, or prompt the user to input the API user info to generate the API calls via REST.
It's just something self contained within UCCX that doesn't rely on external web servers or IT support staff.
Great write up. Thanks for sharing @Anthony Holloway .
Edit - this isn't an attempt to hijack your excellent post. Just sharing an example of how the process you've outlined for securing an http trigger can be used.
No worries Bill. I appreciate the conversation. I came to the same conclusion as you, that the API would not be able to be used with the Agent nor Supervisor credentials. This is actually why I do not store their credentials in the solution, and instead, opted to store the authenticated user object. You could then use this user object in your repo steps like upload document, or, you could simply just check for its existence, and then on their behalf, auth to the API with a pair of admin creds. Don't forget to hide your admin creds though!https://community.cisco.com/t5/collaboration-voice-and-video/uccx-masking-passwords-in-scripts/ta-p/3137357
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: