With keyring functions you can save and get a password with a given service name and username.
Nevertheless, when you check Credential manager in windows (I also tested it in MAC Keychain), the name given to the service is :service:username, where service is the service parameter and username the username parameter passed when keyring::key_set_with_value() is called.
This is not an issue if you access credentials always using keyring package in R. Nevertheless, if you want to access the credential (created with keyring R package) using keyring library in Python, you can access with the original service name but with :service:username. I'm assuming the encoding issue in wndows is under control.
Please, is there any reason why service is modified by R keyring package before it is saved to the windows credential store? Would it not make sense to unify how the package works with its python analogue?
This code, in the keyring key_set_with_value() function example, shows my point. It sets a new secret with service name "R-keyring-test-service" for username "donaldduck"
This is by design, to support a uniform API with keyrings, services and users on all OSes. If you want a non-portable implementation, you can use the oskeyring package instead.
With
keyring
functions you can save and get a password with a given service name and username. Nevertheless, when you check Credential manager in windows (I also tested it in MAC Keychain), the name given to the service is :service:username, where service is the service parameter and username the username parameter passed whenkeyring::key_set_with_value()
is called.This is not an issue if you access credentials always using keyring package in R. Nevertheless, if you want to access the credential (created with keyring R package) using keyring library in Python, you can access with the original service name but with :service:username. I'm assuming the encoding issue in wndows is under control.
Please, is there any reason why service is modified by R keyring package before it is saved to the windows credential store? Would it not make sense to unify how the package works with its python analogue?
This code, in the keyring
key_set_with_value()
function example, shows my point. It sets a new secret with service name "R-keyring-test-service" for username "donaldduck"Created on 2022-10-23 by the reprex package (v2.0.1)
When you look at the secret created in windows credentials, you can see the service name modification