Migrate dialogflow over to the new webhook component#17804
Migrate dialogflow over to the new webhook component#17804balloob merged 5 commits intohome-assistant:devfrom
Conversation
ghost
added
the
|
|
||
| def json(self, result, status_code=200, headers=None): | ||
| @staticmethod | ||
| def json(result, status_code=200, headers=None): |
There was a problem hiding this comment.
I had to expose this and the json_message as static methods so that they could be accessed by things that don't implement HomeAssistantView. Not sure if that is acceptable or if it would be preferred to move them out of the class (within the same module)?
There was a problem hiding this comment.
We should not do this. This is conflation of concerns.
Webhooks should work without any http component related things.
|
This is a Breaking Change |
|
|
||
| try: | ||
| response = await async_handle_message(hass, message) | ||
| return b'' if response is None else HomeAssistantView.json(response) |
There was a problem hiding this comment.
I don't think that it's a webhook when the caller expects a response.
There was a problem hiding this comment.
Forget about the comment above.
However, we should not use HomeAssistantView but instead use aiohttp directly.
from aiohttp import web
return web.json_response(…)
|
https://dialogflow.com/docs/fulfillment/configure DialogFlow supports setting headers so I suggest DialogFlow just uses an authenticated webview with a long lived access token. |
|
Makes sense. I'm going to convert this pull request over to support that then (and keep the async test changes) |
|
We can still use a config entry to tell people what url to use. We might even want to generate a new config flow helper for that? |
|
Sorry, I'm a little lost. Wouldn't they just be using the existing url? Or are you suggesting that we use the config entry to show them that and generate them a long lived access token? In that case I agree, a new config flow helper is probably a good idea. I have one concern with using long lived tokens for things like this. They allow access to everything right? There's no scoping like the webhook component provides. Not a huge fan of using that here for security reasons if that's the correct understanding. If Dialog Flow is comprised, then a lot more damage can be done. |
|
that is a good point. We could use a simliar strategy for generating a url but still have that be registered as a webview, ie |
|
Yeah that makes sense. Couple of other thoughts here: I'm not a huge fan of exposing the purpose of the webview and would prefer if the component name wasn't inside the url. For people whitelisting specific urls to be publicly accessible (for example, I require client certificates for auth on the reverse proxy and whitelist We could call the component |
|
@rohankapoorcom I've been researching webhooks, and I think that you're right, we should allow responses. So let's stick with a webhook for dialog flow. |
houndci-bot
left a comment
houndci-bot
left a comment
There was a problem hiding this comment.
Some files could not be reviewed due to errors:
Traceback (most recent call last):
Traceback (most recent call last):
File "/home/linters/.local/bin/flake8", line 7, in
from flake8.main.cli import main
ModuleNotFoundError: No module named 'flake8'
|
@balloob thanks for the feedback. Changes are committed and pushed up. |
|
Nice! |
5 participants
Description:
Migrating Dialogflow over to the webhook API so that it doesn't need an api password.
Breaking Change: Each instance of Home Assistant will now generate it's own unique webhook url for Dialogflow to use. One will need to be generated and provided to Dialogflow via the webhook integration to replace the existing url:
https://myhome.duckdns.org/api/dialogflow?api_password=HA_PASSWORDI followed the approach used in #16817 to implement a new config flow to register the webhook. Existing configuration (account_sid, auth_token) still occurs via the configuration.yaml file.
I do not actually use dialogflow myself so I cannot test the behavior with Dialogflow , but playing with the request JSON looks okay and all unit tests are passing.
Related issue (if applicable): Related to #15376
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#7109
Checklist:
tox. Your PR cannot be merged unless tests passIf user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
.coveragerc.If the code does not interact with devices: