get_credential user doesn't match supplied user
- Dominant language
- Python
- Stars
- 1.5k
- Forks
- 196
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the bug**
I'm unsure if this is expected behaviour. When multiple credentials are stored and the username is wrong, (it seems) the credentials last stored are returned.
**To Reproduce**
Steps to reproduce the behavior:
```
# Create keyring with 2 users
keyring.set_password('test1', 'username', 'fancy-password-here')
keyring.set_password('test1', 'test', 'test')
# show keyring
keyring.get_keyring()
# correct username
keyring.get_credential('test1', 'username').username
username
# incorrect username
keyring.get_credential('test1', 'user').username
test
# incorrect service
keyring.get_credential('test3', 'username')
None
# add another username
keyring.set_password('test1', 'test2', 'test2')
# attempt 2 with wrong username
keyring.get_credential('test1', 'user').username
test2
```
**Expected behavior**
I'm not a programmer by any stretch, but I think I'd expect an exception raised if the username doesn't match what's requested...
**Environment**
- OS: Windows
```
> keyring --list-backends
keyring.backends.Windows.WinVaultKeyring (priority: 5)
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.chainer.ChainerBackend (priority: -1)
```
**Additional context**
This was a fresh install and no credentials were stored with the python keyring before this. I don't have any other relevant OS's to test with right now.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the Windows.WinVaultKeyring backend and reproduce the issue using the set_password and get_credential calls shown in the report. Trace how a requested username is matched when several credentials share the same service. Done means an incorrect username no longer returns another stored user's credential, with the intended behavior covered by an appropriate test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- security
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100