Proxy endpoint from API for Alexa

[Benjamin_Anderson]

(Read this, then delete it before you post.) To get the best help possible, please:

- explain what you are trying to do,

Create an API endpoint from my domain for use with Amazon Alexa Custom Skill

The proxy is an OWIN server app running on my computer with an endpoint containing JSON information.
I have port forwarded the proper UDP/TCP ports in order for any computer on the subnet to access the main OWIN service.

Note:I also have another proxy which is my emby server (This works)

- show what you have already tried,
Here is my Caddy File:

---

MY-SITE.COM 192.168.2.12:7654 {

    tls ##########@gmail.com

    timeouts none

   proxy /security 192.168.2.18:9920/security/values {
	transparent
	without /security
   }

   proxy /emby localhost:8096 {
	websocket
	transparent
    }

    # Optional security headers
    header / {
	-Server
	Strict-Transport-Security "max-age=31536000;"
	Referrer-Policy "strict-origin"
	#X-XSS-Protection "1; mode=block"
	#X-Content-Type-Options "nosniff"
	#X-Frame-Options "DENY"
    }


    # Optional logging
    log EmbyProxy.log

  # reauth {
#	path /torrent
#	simple admin=####
  
# }

}

---

- include error messages and log output,

The endpoint is responding 404 when attempting to use the proxy to access the endpoint in OWIN through caddy server
.
Alexa responds “undefined”, when attempting to access the caddy proxy endpoint to get the JSON string, because caddy is responding 404 not found.

I was hoping that the proxy: “https://MY-DOMAIN.COM/security” would result in connecting to my OWIN server endpoint.

I thought the proxy would just redirect to the endpoint.

- and link to any relevant resources.
N/A

Please let me know if I have to explain things more clearly.

[Benjamin_Anderson]

Upon further examination the proxy is working as expected.

perhaps I will return after some morning testing to figure out why Alexa custom skills can’t connect to the endpoint.

[Whitestrake (Matthew Fay)]

Hi @Benjamin_Anderson, I’ve edited the OP to add code blocks around your Caddyfile for readability.

The only thing I can think to be wary of is redirects and links and how they interact with the format of the upstream host. If 192.168.2.18:9920 expects a URI beginning with /security/values, and it issues a link to /security/values/foo/bar/xyz, here’s what happens:

• Caddy receives a new request for MY-SITE.COM/security/values/foo/bar/xyz
• The URI matches the proxy base path to be sent to host 192.168.2.18:9920/security/values
• Caddy strips the preceding /security from the requested URI and appends it to the host
• The upstream host receives a request for 192.168.2.18:9920/security/values/values/foo/bar/xyz

Which might not be what it’s expecting…

[Benjamin_Anderson]

Thank you Mathew for taking the time to respond and explain that.

This was one of two of my issues.

After added the proper ‘without’ statement to my Caddyfile I was able to hit the proper endpoint in my API.

So the answer above helped me figure that part out.

The next part that was an issue was how my JSON object was being presented at the endpoint. It was formatted as a JSON string and not an JSON Object…
There is a difference… Escaped characters and wrapped in quotations, as opposed to an object which is not the latter.

The cool thing is that my project works quite well now, taking cctv camera images on request from Alexa and sending a static feed image to Microsoft Cognitive Sense to get a written description of people standing at my front door.

Alexa then describes the people by age, gender and clothing.

You just never know now a days who wants to knock on the door. Call it a little paranoid or maybe just safer. Dunno.