V0.80: new google assistant auth behind proxy redirect issue

Configuration
1

Hi,

I’m trying to re-authenticate the google assistant app.

I’m running Hass.IO behind a reverse nginx proxy.

location /hassioproxy/ {
  include /config/nginx/proxy.conf;
  rewrite /hassioproxy/(.*) /$1 break;
  proxy_pass http://my.local.hassio:8123;

In configuration.yaml I have the entry

http:
  base_url: https://my.external.url/hassioproxy

I can connect to the API endpoint at: https://my.external.url/hassioproxy/api/

When I browse to the authentication url:
https://my.external.url/hassioproxy/auth/authorize
it redirects to:
https://my.external.ul//frontend_es5/authorize.html

But it cant be found there because it’s missing the /hassioproxy/ part.

Anybody any idea how to solve?

1 Like
2

Please follow the guide, the URL should not include hassio. https://www.home-assistant.io/components/google_assistant/#migrate-to-release-080-and-above

3

That’s my reverse proxy part. The url for authorize is correct called, so I assume thats correct. But its then redirected to an url without the proxy part.

4

That is a bug, I guess you have problem to login from external network as well. To make sure Google Assistant OAuth2 flow works, you need first make sure you can login from external network.

5

Checked the source code, we didn’t support your proxy setup, you can raise an issue in https://github.com/home-assistant/home-assistant/issues

As a workaround, you can use https://my.external.url/hassioproxy/frontend_latest/authorize.html as the auth URL

If you have problem to login, you can try to change frontend_latest to frontend_es5 especially for Safari on iOS

1 Like
6

Tnx, when I try that I got a login screen which shows: InitializingScreenshot_2018-10-14%20Home%20Assistant

For that a workaround should be applied as well? I tried both frontends (latest/es5)

7

Are you able to login from external network at all? You have to fix your proxy setting to allow normal login works before you try on Google Assistant.

8

Doesn’t seem to be working indeed. Any advice on were to start debugging?

The image it’s trying to load is also missing the /hassioproxy/

Issue raised on github:
https://github.com/home-assistant/home-assistant/issues/17434

9

Faced the same issue twice and @awarecan + a few posts on stackoverflow about nginx/ha helped me fixed it.
A few things to debug :

  1. Check your /etc/hosts file is clean and that the first 2 lines are 127.0.0.1 localhost.localdomain localhost and “your.private/public.static.ip” fqdn alias1 alias2…)

  2. Update your nginx conf files to change hostname (ie: localhost) to IP (127.0.0.1), do this where you have the issue, you don’t need to update everything.

  3. Nginx produces 2 aggregated logfiles (access & error), we’re only interested in following the most recent errors so we’ll use the command tail -f [location_of_nginx_error.log_file] (ie: tail -f /var/log/nginx/error.log).
    This will tell you who and what are the cause of your issue : maybe you just need to adjust your acls to allow some IPs blocks, otherwise I’m sure you’ll find help to decode the cryptic error codes, that’s where the github issue tracker & community really shine.

  4. The good advice from @awarecan - which also worked without an urlbase (https://my.external.url/frontend_latest/authorize.htm ) - is what brought me back here : YMMV with how much time a sync takes but even after applying this fix, the sync took really longer than usual. Now with the latest upgrade to 0.81.5, the exact same issue came right back.

I don’t live in the US and only heard about the last I/O, the speed at which they rolled-out “multi-language support” or “continued-conversation” made me think at how much it took for VR to take-up. I was so annoyed when I heard that Alexa wouldn’t initially be sold outside the US, now I see why : low latency is essential for a good experience and google_assistant’s actually made their guidelines very clear: “less than 200ms is ideal, between 2-5s is OK. If your latency is hovering around 5 seconds, please talk to us.”

Between GA’s interface update and HA’s batch of improvements, I played with the fail_timeout setting in the upstream directives in hoping to get a more responsive instance.

The suggestions (for other use-cases) were to set it to 0s : “200ms is ideal”, right? .
I could see my callback being made and being dropped, as soon as I increased the value, problem solved.
I hope I won’t spend more time on this issue, rest assured that if I find a sweet-spot I’ll updated my post.

assuming nginx & ha running on same instance

[./nginx.cfg]
…
##
# Logging Settings
##

stream {
upstream my {
server 127.0.0.1:8123 fail_timeout=90;
} }

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

[./sites-availables/external.url]
server {
listen 80;
server_name my.external.url;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name my.external.url;
include ./nginx/snippets/headers_http2.conf;
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains” always;
include ./nginx/snippets/ssl_certificates.conf;
}
location / {
include ./nginx/snippets/acl_all.conf;
proxy_pass http://127.0.0.1:8123;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;
proxy_read_timeout 45;
proxy_set_header X-Forwarded-Proto $scheme;
set $xforwardedssl “off”;
if ($scheme = https) {
set $xforwardedssl “on”;
}
proxy_set_header X-Forwarded-Ssl $xforwardedssl;
proxy_redirect ~^(http(?:s)?://)([^:/]+)(?::\d+)?(/.*)?$ $1$2:$server_port$3;
proxy_buffering off;
}
location /auth {
include ./nginx/snippets/acl_geo.conf;
proxy_pass http://127.0.0.1:8123/auth;
}
location /api/google_assistant {
include ./nginx/snippets/acl_geo.conf;
proxy_pass http://127.0.0.1:8123/api/google_assistant;
}
…
[ nb1: same structure to add other backends like dialogflow ]
[ nb2: websockets are tcp and would require a different approach, ie: haproxy->nginx->ha ]
}