question

mrsean2k avatar image
mrsean2k asked

Can non-https endpoints be used before certification?

As per the title. Is there any way a non-https endpoint can be used while a skill is in development?

At the moment, attempting to use http yields an error that the url must be between 9 and 3000 characters. While it's unarguable that an https endpoint should be required for certification / production, it would be very useful (at least for me) to have that restriction relaxed during development.

In my particular scenario, I test locally then push to IBM Bluemix where the domain I've chosen is associated with my own wildcard certificate.

If the restriction on https was relaxed during development, I can use another domain pointing to my development box's static IP address and this results in a much leaner test end-to-end development cycle, literally save in Sublime and chat to Dot.

I realise there are options to generate the appropriate certificates for my locally hosted instance, but this is a bit of a pain - it always takes me an age to work out and debug the right sequence of events.

I could also just proxy from an otherwise empty bluemix hosted endpoint and switch at the last minute, but this also feels messy compared to a direct call.

"this will never happen" would also be a time-saving - if less welcome - response

alexa skills kitdebuggingcertificationssl
10 |5000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

meep avatar image
meep answered

Hi @mrsean2k

You can't do it quite like you envisage, but there is a solution that works a bit like your proxy idea...

The most straightforward solution is to leverage the existing Lambda infrastructure and simply redirect requests to your own endpoint.

This approach lets you specify a Lambda endpoint which fulfils the Amazon requirement but all that lives there is code that sends and receives skill request and response data to and from your own server.

There are several advantages here. First, you can build your endpoint anywhere you like and using any technology you are comfortable with. Like PHP? that's fine. Suffer from a predilection for Perl? that works too.

The other big advantage is that your code can be built on a http server – no need for certs and the like. While this is a security concern in that all your skill request and response packets are sent over the internet 'in the clear', it does make life that little bit easier.

This method is outlined here, with code....

https://community.home-assistant.io/t/aws-lambda-proxy-custom-alexa-skill-when-you-dont-have-https/5230/26

10 |5000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

mrsean2k avatar image
mrsean2k answered

Hi @meep

Thanks for the response and link.

I think we are suggesting identical solutions, just that I substitute Bluemix for Lambda for the first hop?

In the end I bit the bullet and sorted out https and appropriate certificates on my locally hosted instance - probably more generally useful in the long run and I was chewing up time with some redirection issue I didn't seem to be making much progress on going down the proxy route.

This is fine except that with alexa-js in the mix, when I instantiate an https server in node, although the body.raw data is identical, the slot / slots method / properties are both null, as if the alexa-js middleware is applied inconsistently. The http version works the same as it ever did. Ho-hum.

However I do now have an approx. 5s lifecycle for testing changes and debugging is more fluid, so worth sorting.

10 |5000 characters needed characters left characters exceeded

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.