Cannot link the app in Google Home anymore
6wheels opened this issue · comments
Hi,
I recently updated my docker containers and I reached the rate limit for Letsencrypt certificates.
This implied to relink my HomeAutio.Mqtt.GoogleHome instance to Google Home.
I can see the OAuth call in the logs, but the link fails.
I notice that the access to HomeGraph fails.
For some reason, my Google HomeGraph account fails to load when I tried to access it with the cloud platform.
Any idea?
rate limit for Letsencrypt certificates.
Im not sure how you'd hit that in normal usage. Their rate limiting rules are fairly reasonable, and there's nothing here that would deal with encryption certs, so I'm guessing you are doing something like checking them for expiration too often. I do a cert renew once a day, but those aren't supposed to count toward your limit. Make sure you are RENEWING and requesting NEW certs every night.
For HomeGraph, you have to set up the Google side and get a service account fine to use. Follow these directions, and then put that file in the config directory and make sure your appsettings.Production,config is set up correctly
"googleHomeGraph": {
"agentUserId": "YOURAGENTUSERID",
"serviceAccountFile": "config/googleHomeGraphApi.json"
},
Beyond that, you're going to have to provide some logs.
I use Traefik as reverse-proxy. It generates certificate or renew them when needed. So I didn't mess up anything with certbot.
But I have many services and domains, and I forgot to set the CA server to the staging one. For testing purpose I had to recreate some containers, this is how I exceeded the limit.
So currently, my homeautio instance is using a certificate issued by the LE staging CA server.
Actually, everything was working yesterday. I could sent orders and read values from the Google Home app, the Google Home mini. HomeGraph was getting data and so on.
Then, my devices in the google home app were shown as 'Offline'. I then checked a few things and tried to relink my homeautio instance, but it failed. So I unlinked it. And now I cannot link it again.
When I attempt to link it, the connection page to get the oauth token appears, I enter my user/password, I see "connecting", it goes back to the list of connected services, but my app stays in the list of available services, not the linked ones.
I also tried to change my password (because I previously checked "remember me"), but it stil fails
Tell me which level of log you need and which steps I have to do to make the log relevant.
As I said, I checked up everything on the Google side : actions, homegraph api etc. This is where I noticed that the HomeGraph service account had some problem. I couldn't access its detail.
Things are back to normal now.
Maybe it's on the google side?
Before creating this ticket, I double checked the wiki for the whole setup. I also generated some new signing certificates.
Things are back to normal now.
Soooo back to working ok?
No, it is not working.
Only the home graph is ok. Sorry for the misunderstanding 🙂
It still can't link the app.
Ok. Whats the log say?
I deleted your comment because you posted your entire log which contained sensitive information. Don't do that, it'll leak various token information when your logs contain verbose / debug information.
If you aren't seeing errors in your logs, then Im not sure what to look for here. I haven't used your proxy setup before so I don't know what special issues that might have, but you might pay special attention to the X-Forward discussion here.
You said you regenerated the signing certificates according to this? There was a breaking change in 2.0 around these and they have to be regenerated or you'll see errors in your log about the certificate not being good.
Can you post your (REDACTED!!!) appsettings.Production.config? I can check and see if that looks right.
You said you already had this working before, so I'm going to assume your Google Actions setup is still good (especially the auth sections of that).
I would probably stop the app, delete the log, start it up, and immediately run a link to get a log that contains just that piece. I tend to find Verbose logs hard to read in this case with a lot of superfluous information, so I'd suggest setting that down to "Information" first.
Google will mark devices as "offline" usually when they do a SYNC / device query and they get an error. I don't see any such attempts in this log, but I'm guessing that was in a previous log before you tried relinking. That would PROBABLY point to issues in your googleDevices.json also, but lets get you linked back first, and then those errors will be much more obvious.
Also, probably obvious, but make sure you are running the latest container version.
Hi Michael,
Thanks for your time.
I deleted your comment because you posted your entire log which contained sensitive information. Don't do that, it'll leak various token information when your logs contain verbose / debug information.
Ok, sorry, I was not sure about the JWT token, thanks for pointing it out.
If you aren't seeing errors in your logs, then Im not sure what to look for here. I haven't used your proxy setup before so I don't know what special issues that might have, but you might pay special attention to the X-Forward discussion here.
I'll check the headers today.
You said you regenerated the signing certificates according to this? There was a breaking change in 2.0 around these and they have to be regenerated or you'll see errors in your log about the certificate not being good.
Yes, I generated new certifcates at the beginning of the week, according to the wiki.
Can you post your (REDACTED!!!) appsettings.Production.config? I can check and see if that looks right.
{
"appPathBase": "/",
"mqtt": {
"brokerIp": "mqtt",
"brokerPort": 1883,
"brokerUsername": null,
"brokerPassword": null,
"brokerUseTls": false
},
"googleHomeGraph": {
"agentUserId": "my-app-id",
"apiKey": "my-api-key",
"serviceAccountFile": "config/ghbridge-googleserviceaccount.json"
},
"oauth": {
"authority": "https://mydomain.tld",
"requireSSL": false,
"clients": [
{
"clientId": "my-client-id",
"clientSecret": "my-client-secret",
"clientName": "Google Home Bridge",
"allowedRedirectUris": [ "https://oauth-redirect.googleusercontent.com/r/my-app-id" ],
"refreshTokenLifetime": 365,
"refreshTokenReuse": false
}
],
"users": [
{
"subjectId": "my-uuid",
"username": "my-user",
"password": "my-password"
}
]
},
"Serilog": {
"Enrich": [ "FromLogContext" ],
"MinimumLevel": "Information",
"WriteTo": [
{ "Name": "Console" },
{
"Name": "RollingFile",
"Args": {
"pathFormat": "logs/HomeAutio.Mqtt.GoogleHome.log",
"retainedFileCountLimit": 31
}
}
]
}
}
I would probably stop the app, delete the log, start it up, and immediately run a link to get a log that contains just that piece.
This is exactly what I did yesterday and posted the corresponding log.
I tend to find Verbose logs hard to read in this case with a lot of superfluous information, so I'd suggest setting that down to "Information" first.
Here is the log:
Google will mark devices as "offline" usually when they do a SYNC / device query and they get an error. I don't see any such attempts in this log, but I'm guessing that was in a previous log before you tried relinking. That would PROBABLY point to issues in your
googleDevices.jsonalso, but lets get you linked back first, and then those errors will be much more obvious.Also, probably obvious, but make sure you are running the latest container version.
Yes, I use the latest docker image. I did clean the log, actually the whole container's data, before posting the log you deleted.
I didn't change any device, so I doubt this is related to the device config. But I can post it if you need.
Thanks again.
None of the X-Forwarded-For and X-Forwarded-Proto headers are set, I'll add them and report. But I never set them before, and my first Homeautio install was in December 2020.
I also notice that there are some 404 errors when accessing to HomieGraph (it's in the log).
HomeGraph will error when Google doesn't know about the device you are reporting yet (i.e., it hasn't done a link and a SYNC yet to get devices). I.e., not surprising in your current state.
You definitely need to add the X-Forward headers to your proxy config. The app will read these to help it build URLs that it needs to build (such as the IDP metadata URLs, the redirect URLs used during auth handshake, and others). Without these, it will try to build them to the URL it knows about in the container: http://0.0.0.0:5000, which should instead be (based on your config there), https://mydomain.tld
Your config for the oauth parts seems to be missing some pieces. It doesn't look like you are specifying the token file store location or the signingCerts.
"oauth": {
"tokenStoreFile": "config/tokens.json",
"authority": "https://mydomain.tld",
"requireSSL": false,
"signingCerts": [
{
"file": "config/signingKey.pfx",
"passPhrase": "YourPass"
}
],
"clients": [
{
"clientId": "my-client-id",
"clientSecret": "my-client-secret",
"clientName": "Google Home Bridge",
"allowedRedirectUris": [ "https://oauth-redirect.googleusercontent.com/r/my-app-id" ],
"refreshTokenLifetime": 365,
"refreshTokenReuse": false
}
],
"users": [
{
"subjectId": "my-uuid",
"username": "my-user",
"password": "my-password"
}
]
},
Also your Serilog section looks off if you are using the latest version. Use this instead:
"Serilog": {
"Enrich": [ "FromLogContext" ],
"MinimumLevel": "Information",
"WriteTo": [
{ "Name": "Console" },
{
"Name": "File",
"Args": {
"path": "logs/HomeAutio.Mqtt.GoogleHome.log",
"rollingInterval": "Day",
"retainedFileCountLimit": 31
}
}
]
}
}
I updated my config (logger and certificate path).
For the signing certificate path, I thought that the default path value would be used if it wasn't set it in the appsettings.
For the headers, I've tried many things and checked the traefik's access logs.
Only the X-Forwarded-For is missing, and I actually don't know how to add it.
To confirm an potentiel header problem, I'll install nginx and use the configuration given in the wiki.
But I really don't understand why it worked before.
Keep in touch.
There is no "default path" for the certificates, no. That wouldn't make any sense given you need extra data about the cert (passphrase) to use it, so just a default path is insifficient.
If you leave it out, it'll try and generate a "development" cert for use only during my development. This can work temporarily in some cases, but SPECIFICALLY will die very quickly because its only meant for short term use (I think its like a day). You have to tell it where your cert is.
Same thing with tokenStoreFile, there is no default path for these, you have to specify them. That LAST one I could probably change to use a default path, but there's definitely not a guard there now.
Hi Michael,
I finally made it work, and it has nothing to do with the X-Forwarded-For header.
But by default, Traefik adds the X-Forwarded-Proto header.
It was only due to the certificate issued by the staging CA server.
I didn't take more time to test with nginx as it's now working again.
I don't know if this has recently changed, but now Google requires a valid SSL certificate issued by a well known CA server.
No, Google has always required that I believe. If they didn't Im pretty sure I wouldn't have bothered with LetsEncrypt certs way back when I first got this working.
It would be worth stating this information in the wiki, if you haven't already.
Anyway, my problem is solved, closing, thanks.