Skip to content

Common Issues

Jump to bottom
Michael Hallock edited this page Sep 6, 2020 · 3 revisions

This is a collection of common issues and how to fix them.

When proxying and accessing /Account/Login, CSS and image files don't load

This is usually because you are proxying the application at a URL other than the root URL (i.e. https://yourUrl/google/home). The application, however, will assume that it is running at http://localhost:5000, and will generate any links it creates based on that assumption.

The application must be told what URL it is being proxied at by setting the environment variable ASPNETCORE_PATHBASE to the root-relative path the application will actually be exposed at. i.e., in the example above, you'd want to set it to /google/home.

Note: This can also be due to bad proxy configurations. For instance, if you have a more generic nginx configuration that might match before your location proxy, it can hijack the request. The below generic rule, for instance, has caused issues for some people, so if you see the right URLs but still have issues, check that for bad proxy configurations.

    location ~*  \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 365d;
    }

You can check the logs generated by this app to see if your requests for files are actually hitting the application.

I see [Error] Client secret validation failed for client: "MYCLIENTID" in the log, and Google won't connect correctly.

This error indicates that the client secret does not match between your Google Actions Console setup and the value in your configuration. Ensure these match.

User interface changes result in "502 Gateway Not Found" when proxying through nginx

It turns out nginx is a little light on buffer allocation when proxying sites, and some of the auth headers can be bigger than their default 4k. Adding the following to your proxy configuration should alleviate this:

    proxy_buffers 8 16k;
    proxy_buffer_size 16k;

Application links / forms point at the wrong URL

This is an indicator that your proxy setup is not sending through X-Forward headers. Please see the documentation for your web server's proxy setup and make sure these are being provided.

Frequent having to relink in Google Home

Disassociation from Google Home can be a symptom of several issues around authentication. Often this occurs due to refreshToken failures, which will be apparent in the log. There are a few settings you can use to try and change how refreshTokens are used to try and work around poor connections. While it's recommended to handle the underlying issues instead of using these, they are provided as options.

  1. Set the configuration value oauth.refreshTokenGracePeriod. When set to a non-zero value, this will allow for Google sending multiple commands requiring refresh token renewal with the same refreshToken within the grace period time. This can be handy when for some reason responses take longer than 5 seconds to return to Google, as it can send multiple requests in that time period, and eventually will leave itself without a valid token.
  2. Set the configuration value refreshTokenReuse on oauth.clients. This will make refreshTokens reusable instead of expiring after first use, so the same refresh token can be used until its expiration. In a worst case scenario, this can allow Google to make new token calls reliably all the way to the refresh token's expiration, so at least the window for it to fail will only happen around that expiration time. There are security repercussions to this setting should Google get hacked and leak their token store, but should be an acceptable risk for use here (i.e., its LESS secure, not INSECURE).
Clone this wiki locally