Closed WiliTest closed 6 months ago
I get the very same error, I am trying to login with my email address and password. Less secure apps are enables in my google settings.
Is there any solution for this?
File "/usr/local/lib/python3.7/site-packages/gkeepapi/init.py", line 693, in login ret = auth.login(username, password, get_mac()) File "/usr/local/lib/python3.7/site-packages/gkeepapi/init.py", line 60, in login res.get('Error'), res.get('ErrorDetail') gkeepapi.exception.LoginException: ('BadAuthentication', None)
I'm getting the same error with both account password without 2fa and app password with 2fa. Please help anyone??
I tried to modify script and get oauth token by "legal" ways of oauth2, but to use that token for API, that particular API must be enabled for your account account, and as Google Keep API is not supported officially, there is no way to enable it for the token.
Here is the error I'm getting while using oauth2
gkeepapi.exception.APIException: {'errors': [{'domain': 'usageLimits', 'reason': 'accessNotConfigured', 'message': 'Access Not Configured. Reminders API has not been used in project 1052062629689 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/reminders.googleapis.com/overview?project=1052062629689 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.', 'extendedHelp': 'https://console.developers.google.com/apis/api/reminders.googleapis.com/overview?project=1052062629689'}], 'code': 403, 'message': 'Access Not Configured. Reminders API has not been used in project 1052062629689 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/reminders.googleapis.com/overview?project=1052062629689 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.'}
I'm getting the same error with both account password without 2fa and app password with 2fa. Please help anyone??
I tried to modify script and get oauth token by "legal" ways of oauth2, but to use that token for API, that particular API must be enabled for your account account, and as Google Keep API is not supported officially, there is no way to enable it for the token.
Here is the error I'm getting while using oauth2
gkeepapi.exception.APIException: {'errors': [{'domain': 'usageLimits', 'reason': 'accessNotConfigured', 'message': 'Access Not Configured. Reminders API has not been used in project 1052062629689 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/reminders.googleapis.com/overview?project=1052062629689 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.', 'extendedHelp': 'https://console.developers.google.com/apis/api/reminders.googleapis.com/overview?project=1052062629689'}], 'code': 403, 'message': 'Access Not Configured. Reminders API has not been used in project 1052062629689 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/reminders.googleapis.com/overview?project=1052062629689 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.'}
Here is the script I used to get API token (if anyone needs it)
import os
from google_auth_oauthlib.flow import InstalledAppFlow
CLIENT_SECRETS_FILE = "secrets.json"
SCOPES = ['https://www.googleapis.com/auth/memento', 'https://www.googleapis.com/auth/reminders']
if __name__ == '__main__':
os.environ['OAUTHLIB_INSECURE_TRANSPORT'] = '1'
flow = InstalledAppFlow.from_client_secrets_file(CLIENT_SECRETS_FILE, SCOPES)
credentials = flow.run_console()
print(flow.credentials.token)
@kiwiz gkeepapi has been working pretty fine for the last 3,4 weeks and now suddenly I got this error! Could anyone please suggest a fix for this, because my app really depends on gkeepapi, and without this working, its really affecting me!
I've been getting the same issue. does this mean a google keep api is coming?
try using python3.7.7
also getting this, just now addressing it. last successful login was April 9. I've tried regenerating the app password, and also clean installing latest version on a different system. running python 3.5.3 on a pi3 for one install and 3.5.2 on an Xenial pine64 for the other. is 3.7 really the solution for this? doesn't seem like it should matter.
@wilsonmfg - see issue #86 to fix this.
I'm using python 3, and it's a new clean install. I'm not sure how that "fix" applies
@wilsonmfg - hmmmm.....I had the same issue. So what I did was upgrade my Anaconda install to Python 3.7.7 and also updated this library to the latest version (pip install --upgrade gkeepapi) and that fixed the issue.
which goes back to my question, is 3.7 actually needed or just 3.x? 3.7 is not an easy fix on a Pi.
agreed! seems the python version shouldn't make any difference. @kiwiz - any thoughts here?
@wilsonmfg - hmmmm.....I had the same issue. So what I did was upgrade my Anaconda install to Python 3.7.7 and also updated this library to the latest version (pip install --upgrade gkeepapi) and that fixed the issue.
This solved it for me, i used pyenv to manage the python versions and made sure the latest version of python was being used (3.8.5). https://opensource.com/article/19/5/python-3-default-macac was helpful - see the 'what we should do section in particular'
that link doesn't work.
No luck here either.
Try testing on another system/another account to see if you can isolate the cause of the issues. As for why Py3 is being suggested, see https://github.com/kiwiz/gkeepapi/issues/69 for more details.
I did. https://github.com/kiwiz/gkeepapi/issues/81#issuecomment-653927029
Installing a new python 3.7 env did solve it for me.
This didn't work for me with either 3.7.7
, 3.9.0
, 3.6.12
pyenv install x.x.x
pyenv shell x.x.x
pip install --upgrade gkeepapi
@givanse - when you did your tests - were you logged into your Google account on your default browser? And, did you try using the step to UnlockCaptcha manually link at all after you first authenticated? I tried a fresh Debian install recently and it worked fine.
Hadn't thought about the potential for issues if more than one account is logged in, I'll check on that, thanks.
Got the same issue here... running on python 3.9, followed all instructions in the FAQ. Anything new?
EDIT: It doesn't work on macOS, but it does on linux (on python 3.8.6). Hope this can help.
Has anyone found a solution? Also does not work
Logger: homeassistant.components.sensor
Source: custom_components/google_keep/sensor.py:39
Integration: חיישן (documentation, issues)
First occurred: 3:02:30 (1 occurrences)
Last logged: 3:02:30
Error while setting up google_keep platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 199, in _async_setup_platform
await asyncio.shield(task)
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/google_keep/sensor.py", line 39, in setup_platform
login_success = keep.login(username, password)
File "/usr/local/lib/python3.8/site-packages/gkeepapi/__init__.py", line 693, in login
ret = auth.login(username, password, get_mac())
File "/usr/local/lib/python3.8/site-packages/gkeepapi/__init__.py", line 59, in login
raise exception.LoginException(
gkeepapi.exception.LoginException: ('BadAuthentication', None)```
Mines intermittent, every 4 in 5 reboots of Home Assistant nets this error, however it does still work if I keep rebooting it enough. When it does succeed, it works completely fine. I've tried using 0.13.1 and it doesn't appeared to have made it any better.
Having the same issue (using HA. Started seeing after upgrading to 0.118). Tried running a python (Python 3.8.6) snippet to test:
import gkeepapi
keep = gkeepapi.Keep()
success = keep.login('foo@gmail.com', 'barbarbarbar')
Using 2FA; I even created a new app password for testing reasons; Tried the Unlock Captcha idea - doesn't work:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python3.8/site-packages/gkeepapi/__init__.py", line 693, in login
ret = auth.login(username, password, get_mac())
File "/usr/local/lib/python3.8/site-packages/gkeepapi/__init__.py", line 59, in login
raise exception.LoginException(
gkeepapi.exception.LoginException: ('BadAuthentication', None)
Shooting in the dark, as I'm not a python developer. Could there be an issue with the get_mac() function?
>>> get_mac()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'get_mac' is not defined
@callifo If you get a valid session, you should consider caching it to reduce the chance of issues with authenticating: https://gkeepapi.readthedocs.io/en/latest/#logging-in
@maximunited The get_mac
method is pulled from the uuid
module. If you want to try providing an alternate value, I've exposed that in v0.13.2
. To generate a device_id
, try the following:
'ios:' + str(uuid.uuid4())
os.urandom(8).hex()
Then call the login method: keep.login(user, password, device_id)
.
If the device_id
works, you should save it and pass it every time (in other words, don't generate a new id each time you log in).
I was playing around with the gkeepapi version used by this component, and moved to 0.13.1 instead of the 0.11.x version in the latest release, and it was happening less often.
Then a few days ago, mine actually stopped with the Bad Auth messages completely. Between when I was testing 0.13.1 and now, I've changed absolutely nothing...
Edit: Nope, back again within a week.
Ok, just hit a snag @kiwiz . I was running python 3.7.7 and gkeepapi 0.11.8 successfully for the last 6 months on Windows 10. Updated to python 3.7.9 and gkeepapi 0.13.3 and I cannot log in. Tried turning off 2FA and using the captcha link. Also, tried a different account and different IP - no luck. On my Debian 10 instance I have python 3.7.3 and gkeepapi 0.13.1 and it works without any issues first time. Tried reinstalling fresh version on Windows of Python 3.7.9 and 3.8.6 with gkeepapi 0.11.x and 0.13.x with no luck.
As I think through this - wondering what is unique about Linux vs Windows. What might be blocking Windows authentication?
PS - just tried it on a Mac Catalina 10.15.7 running python 3.7.3 and gkeepapi 0.13.1 - worked first time without doing anything. And, tried reinstall of 3.7.3 and 0.13.1 on Windows - still no luck
PSS - updated Mac to python 3.7.9 and gkeepapi 0.13.3 and it worked fine. Still can't get Windows to authenticate - still errs to gkeepapi.exception.LoginException: ('BadAuthentication', None)
Other things I've tried on Windows 10:
All failed - what's really odd is how fast the BadAuthentication comes back so quickly. Feels like I'm being blocked on the edge. My Linux VM is on the same PC which works.
@djsudduth Does it work if you copy a working master token from one of the working systems to the Windows one?
Try using the Keep.resume()
method like so:
keep.resume("user@email.com", "master_token")
@kiwiz - interesting idea! I will try it. In the mean time I was digging into gpsoauth to see if there might be something going on with Windows there.
@kiwiz Keep.resume() worked! What does that tell you? It seems to make sense if the token is common.
When i run the app in my pc works fine but when i try to deploy it to Heroku gkeepapi.exception.LoginException: ('BadAuthentication', None)
@djsudduth My best guess is that it's related to this. If you're the mood to debug, it might be interesting to record PCAPs of the TLS traffic on Windows vs Linux to see what the differences are.
It might be easiest to just copy over the master token instead of getting authentication to work. Note that the master token has full access to your account - you should take care when storing it.
@julianfere the above might work for you too.
@kiwiz thanks - I might just do that. What nags at me however, is that it was working on this Windows PC before when it was using Python 3.7.3 and gkeepapi 0.11.8 and only stopped when I updated to 3.7.9 and 0.13.3. Now, I was using Anaconda which updated a lot of Python packages as well. How that relates to TLS is odd to me since all 3 of my Windows 10 PCs in the house all fail with different versions of Python and gkeepapi (and different VPN IPs).
Makes me want to try installing Anaconda again in the same way. As for PCAPs - might try it but that's a lot of work.
Was looking at something else about Python and found this (not sure it means anything) - but I was using 3.7.3 when Windows was working: "Python uses OpenSSL as its TLS implementation. Python v3.7.4 and later use OpenSSL v1.1.1. Python v3.7.0 to v3.7.3 use OpenSSL v1.1.0. Earlier versions of Python use OpenSSL v1.0.2. On Windows and macOS the standard Python binary installers include copies of the corresponding OpenSSL libraries."
@kiwiz - here's what I tried tonight: went back and installed Anaconda 2019.07 which was what I had when it worked (python 3.7.3) - then installed gkeepapi 0.11.7. The only packages installed for gkeepapi were: gpsoauth 0.4.1 pycryptodomex 3.9.4
all other requirements were satisfied by Anaconda: six 1.12.0 future 0.17.1 requests 2.22.0 certifi 2019.6.16 chardet 3.0.4 urllib3 1.24.2 idna 2.8
It definitely acted different but failed with - feels like I missed something - JSON errors??: File "keep-test.py", line 21, in keep_login keepapi.login(userid, pw) File "C:\ProgramData\Anaconda3\lib\site-packages\gkeepapi__init.py", line 549, in login self.load(auth, state, sync) File "C:\ProgramData\Anaconda3\lib\site-packages\gkeepapi\init.py", line 595, in load self.sync(True) File "C:\ProgramData\Anaconda3\lib\site-packages\gkeepapi\init.py", line 850, in sync changes = self._reminders_api.list() File "C:\ProgramData\Anaconda3\lib\site-packages\gkeepapi\init.py", line 458, in list json=params File "C:\ProgramData\Anaconda3\lib\site-packages\gkeepapi\init.py", line 220, in send response = self._send(req_kwargs).json() File "C:\ProgramData\Anaconda3\lib\site-packages\requests\models.py", line 897, in json return complexjson.loads(self.text, kwargs) File "C:\ProgramData\Anaconda3\lib\json\init__.py", line 348, in loads return _default_decoder.decode(s) File "C:\ProgramData\Anaconda3\lib\json\decoder.py", line 337, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "C:\ProgramData\Anaconda3\lib\json\decoder.py", line 355, in raw_decode raise JSONDecodeError("Expecting value", s, err.value) from None json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
@djsudduth Hmm, can you edit the line at C:\ProgramData\Anaconda3\lib\site-packages\gkeepapi\_init_.py
to print out the results of the send()
call like so print(self.send(**req_kwargs))
and report the output? If there are any IDs or tokens, please replace them with placeholder values.
Do you need to do anything in the google account settings to authorise the connexion through this api?
What is this master token being discussed? Can I get one if, for example, my browser is logged in to Keep?
See gpsoauth for details. tl;dr it's the flow that Google Play Services uses to authenticate with Google.
@simon-weber suggests pinning requests
to version 2.23.0
over on the gpsoauth issue for the same error. This resolved the issue for me.
https://github.com/simon-weber/gpsoauth/issues/24
@JamesGlover @kiwiz - went to one of my Windows test machines and downgraded requests
to 2.23.0
- that did work for me as well! Also, just tried it on my development Windows PC and it worked there.
@JamesGlover good find! I've bumped the version and pinned requests
to 2.23.0
(only on Windows).
Looking at issues on other repos, it seems like people on OSX and Linux might be affected by the same issue too. If someone has time, I'd be curious how a request generated by 2.23.0
differs from a more recent version.
Super hacky alternative fix:
# Put this at the top of your code (before any imports)
import ssl
del ssl.HAS_SNI
@kiwiz I've had no issues with both Linux and OSX with the later releases. For Windows, if I had a standard Python install - my 2 test cases works with 2.23.0
. However, on a 3rd Windows test case using Anaconda trying to revert to 2.23.0
didn't work even though all libraries including chardet
and urllib3
reverted. I also tried the super hacky alternative and that didn't work either.
Any thoughts on why removing the SNI (Server Name Indication) flag from TLS fixes this?? Reading the RFC - is there a client/server name conflict here???
"If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication. TLS implementations are encouraged to make information available to application callers about warning- level alerts that were received or sent during a TLS handshake. Such information can be useful for diagnostic purposes."
It seems that versions of requests
after 2.23.0
default to ssl
instead of pyopenssl
. By unsetting HAS_SNI
, the code should fall back to pyopenssl
.
It sounds like it might be a separate issue with that Windows test box. :thinking:
Yeah, I think so too. I'm going to reinstall Anaconda on a box and try it. What's odd about ssl
vs pyopenssl
is that Mac and Linux work fine. Wondering what's in the Windows 10 OS that is causing the issue for the ssl
lib?
I tried to run this code , it gives me the error above.
I tried with the Gmail login and password, then with my email login and an "app password" following these step:
other
, I named itgkeepapi
and I generated a password.