New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERROR for site owner: Invalid domain for site key #20
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Please +1 instead of posting a me too post. The proxy doesn't touch the recaptcha traffic. Please check your browser to see what recaptcha urls you are hitting. Then please compare with the regular auth.tesla.com page. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
So I investigated this. It looks like Tesla has tightened the captcha security so it compares the captcha page against the page in the browser. This obviously fails the proxy. This happens due to JavaScript. Because we're using python, there's not really much more we can do to get around it. Python will not process JavaScript and passing it to a browser that isn't looking at auth.tesla.com fails the JavaScript test. While JavaScript could be intercepted and overridden, it's frail and likely to be a problem in the future. There are some discussions here: timdorr/tesla-api#390. The main issue is approaching the api and not getting the initial captcha. I'll continue to think about how to get around this but we may be done. |
This comment has been minimized.
This comment has been minimized.
My current solution is... involved... Using this code and some network trickery: I'm running HA in a docker container, and I have the SSH server enabled on my computer (a MacOS). From within the docker container I run the command:
Then, I have updated my
I then go to my browser on my computer, and navigate to http://auth.tesla.com:8123/ - if everything is working, it'll give you your HA login screen, login, and start the process to add this custom integration. I found on the the popup page that it used my default URL, update just the protocol/domain/port portion (ie: change the start to http://auth.tesla.com:8123 ), then you can login to the Tesla page as you would normally. When things start working in HA, remove the line you added to your There maybe better solutions - but this is the only one I can think of without hacking / running JavaScript in Python (or something similar). |
Genius. I wanted to test a similar trick, but thought they would compare the whole URL and not just the web site. |
Thanks. I've confirmed the workaround works from @sillyfrog . Here's how you do it with less steps but potentially two browsers. You only need to use the auth.tesla.com redirect to get past the first step. It's possible that if you get prompted by MFA or some other secondary page, the login will break but luckily the component remembers the state it's in.
|
GENIUS... WORKED..... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The 500 error is a different error and we'll need logs to help. Please open a new issue and post the requested logs. It's not clear to me from your description but the HA system must have access to auth.tesla.com so if it's picking up the hosts changes that will break things. The instructions assume your HA and browser machine use different hosts files. |
This comment has been minimized.
This comment has been minimized.
That's expected. Only your local browser should be fooled to go to HA, your HA should be able to reach the actual auth.tesla.com |
So, we're removing Tesla from core and will need to consider what to do with the custom component moving forward . I am looking for input on whether we continue with this workaround using the proxy or switch to requiring a 3rd party application to provide the refresh token. If you have an opinion, please answer here. |
This comment has been minimized.
This comment has been minimized.
I can also confirm that the workaround documented above by @alandtse doesn't work when HA is configured to only communicate via HTTPS. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I've created a new bug regarding the 500 error. If you're also hitting this bug, either reply with some logs if they differ from mine, or just +1/star/subscribe to it. Please do not reply back with a "me too" comment as it's not helpful. Also the editing of the hosts file work around is dirty as hell and I applaud @sillyfrog for such a good hack. |
Tried latest version (with token) after generating a token and testing it using curl commands. The login failed:
EDIT: Used wrong token (access instead of refresh) |
Seems to work. Thanks for your efforts! |
If this custom integration is already configured, will the authentication fail at some point? (i.e. after 45 days when the token expires) - or since it's already configured and has valid tokens, will it just continue to renew them in the background without going through the setup process again? |
That's really a question for Tesla. So long as they accept your refresh token, then it will keep getting new access tokens. If they invalidate your refresh token, then you have to get a new one. |
Answer appears to be "yes". It failed. |
Same here, my token expired. I didn't request a token for anything else |
This trick with updating the hosts file worked for me in September but now my token was invalidated again and this time when I use Broswer B I get:
From http://auth.tesla.com:8123/auth/tesla/proxy?config_flow_id=.... Any ideas? Edit:
|
Why not just use the refresh token? Has been working well for me for a month or 2. |
This I have missed... But... I have installed the Auth Token app for Android and cleared the cache in my browser and also reinstalled the Tesla Custom Component version 1.3.1. But when searching it seems like I get the wrong version when trying to configure the integration? What have I missed? |
Did you try all the items in the thread you reference? Looks like several of us had success uninstalling/reinstalling HACS. |
I can try to uninstall hacks, but that will be Tomorow. But just to confirm, this should work with version 1.3.1 right? |
Right |
I got it to work. It seems like there was two Tesla directories inside /config/custom_components One named tesla_custom and one tesla. I uninstalled the Tesla custom integration which also removed tesla_custom however the Tesla directory didn't seem to belong to an installed custom component.
Then I got the proper UI in the browser when I added the integration in Configuration -> Integrations -> + Add Integration Thank you for pointing me in the right direction and I hope this helps if someone else have the same problem in the future. |
Version of the custom_component
0.2.1
Configuration
n/a
Describe the bug
In the tesla login page that is proxied, the Captcha doesn't load
Page URL in browser is :
Debug log
I have a reverse proxy for Home Assistant, it seems to whitelist its IP correctly
EDIT BY ADMIN:
WORKAROUND:
#20 (comment). All credits to sillyfrog.
The text was updated successfully, but these errors were encountered: