Problem if wrong password entered after reset
See original GitHub issueChanged my Okta password, and as expected the gimme-aws-creds call first failed, then prompted me for a new password.
I entered the old password by accident, which got written to the Keychain gimme-aws-creds entry.
This resulted in an error I couldn’t get around until I updated the Keychain entry with the proper password (I suppose I could have removed the entry from the Keychain as well).
Expected Behavior
Ideally, when the password fails, it should always prompt for the password to be entered, and it shouldn’t write the password to the Keychain until it has successfully logged in.
Current Behavior
When login fails after password change, the login fails. User must run gimme-aws-creds a second time to get the password prompt. There is a question asking if this should be written to the Keychain, but the password is not validated prior to the write leaving the client in a bad state.
Possible Solution
Don’t write the password to keychain until after it succeeds. And probably always prompt for the password when the one in the Keychain fails.
Steps to Reproduce (for bugs)
- Change the password in the Keychain to something bogus OR change your Okta password
- Run gimme-aws-creds
- If prompted for password, give it a bad password
- Once the bad password is in the Keychain, you should see something like:
Using password from keyring for robweaver@workfront.com
Traceback (most recent call last):
File "/usr/local/bin/gimme-aws-creds", line 17, in <module>
GimmeAWSCreds().run()
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/main.py", line 447, in run
self._run()
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/main.py", line 738, in _run
for data in self.iter_selected_aws_credentials():
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/main.py", line 714, in iter_selected_aws_credentials
for role in self.aws_selected_roles:
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/main.py", line 632, in aws_selected_roles
selected_roles = self._get_selected_roles(self.requested_roles, self.aws_roles)
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/main.py", line 623, in aws_roles
self.saml_data['SAMLResponse'],
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/main.py", line 614, in saml_data
self._cache['saml_data'] = saml_data = self.okta.get_saml_response(self.aws_app['links']['appLink'])
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/main.py", line 607, in aws_app
self._cache['aws_app'] = aws_app = self._get_selected_app(self.conf_dict.get('aws_appname'), self.aws_results)
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/main.py", line 560, in aws_results
self.okta.auth_session()
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/okta.py", line 156, in auth_session
login_response = self.auth()
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/okta.py", line 145, in auth
flow_state = self._login_username_password(None, self._okta_org_url + '/api/v1/authn')
File "/usr/local/lib/python3.7/site-packages/gimme_aws_creds/okta.py", line 336, in _login_username_password
response.raise_for_status()
File "/usr/local/lib/python3.7/site-packages/requests/models.py", line 940, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 401 Client Error: Unauthorized for url: https://workfront.okta.com/api/v1/authn```
<!-- And so on -->
## Context
<!--- How has this issue affected you? What are you trying to accomplish? -->
<!--- Providing context helps us come up with a solution that is most useful in the real world -->
## Your Environment
<!--- Include as many relevant details about the environment you experienced the bug in -->
* App Version used: gimme-aws-creds 2.2.0 (was also using 2.1.0 prior to having this issue)
* Environment name and version:
* Operating System and version: Mac OS X
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:11 (2 by maintainers)
Top Related StackOverflow Question
This has been fixed in v2.3.1, thanks!
Same for sure - I haven’t seen any cases where the keychain doesn’t get cleared out.