React-native-keychain: How do i store other info in keychain except username and password

[hejiaji]

could it support to store other custom property like 'token', 'certification' or any other info rather than username and password?

As i see now it only supports these two properties which is a restriction to us

[hejiaji]

@oblador @vonovak

[vonovak]

You can serialize what you need to json and save it as the password. Then
you just deserialize the password.

On Oct 19, 2016 07:56, "Jeremy He" [email protected] wrote:

@oblador https://github.com/oblador @vonovak
https://github.com/vonovak

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/oblador/react-native-keychain/issues/36#issuecomment-254717717,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABfmw6r1AylmQye-T3rWA6LMuKm3_I6Zks5q1bEqgaJpZM4Kalor
.

[hejiaji]

Ok, makes no sense to me, but seems like it's a only way

[dannyharding10]

I would love to have a feature like this. Storing key-value pairs would be a huge plus. I wish there was a function like Keychain.setValueForKey('myKey', 'myValue'), and then you can get that value with something like Keychain.getValueForKey('myKey'). Right now you have to store pairs of data of usernames and passwords which is not optimal for simply storing a token or a password by itself.

[hejiaji]

@dannyharding10 That's the exact feature i wanted

[leomeloxp]

Is there an actual practical difference between the two?

• Keychain.setGenericPassword(username, password)
• Keychain.setValueForKey('myKey', 'myValue')

I believe you can achieve the same end result by just using the generic password approach. I'm interested to know any challenges you find with this though, as this is one of the use cases I'm about to implement on an app.

[dannyharding10]

One challenge would be if your app interfaced with multiple APIs and it had to store a token for each one. You could only store one or two in the generic password. There would be ways to get around this, but they're not great solutions because it would make the code hard to understand. I ended up using the generic password myself because I only had to store one token, but this is still not optimal because generic password is meant for storing a username and a password pair.

[dani-mp]

I agree with you, guys. It'd be great to have a simple API to store a key-value pair.

[MacKentoch]

As answered @vonovak you can just serialize your data (like JSON.stringify) to store any key-value data.

[dani-mp]

Hey, @MacKentoch, thanks for answering.

My problem is not storing an object, but to store some info (a string, a stringified object...) under a certain key so I can retrieve it later, easily. What I'm doing right now is:

Keychain.setInternetCredentials('KEY', 'RANDOM_STUFF', 'value').then(() => console.log('Done'))
Keychain.getInternetCredentials('KEY').then(({ password }) => console.log('Got it', password))

but ideally we need

Keychain.setValueForKey('KEY', 'value').then(() => console.log('Done'))
Keychain.getValueForKey('KEY').then(value => console.log('Got it', value))

I don't know if I'm doing it in a good way, or if there is a better one with the current API.

Thanks.

[MacKentoch]

@danielmartinprieto I had this kind of need.

I just used optional parameter service of genericPasswordmethods as a KEY.
My data (JSON version of an array of object) was the VALUE

   function getGenericPassword(
        service?: string
    ): Promise<boolean | {service: string, username: string, password: string}>;

    function setGenericPassword(
        username: string,
        password: string,
        service?: string
    ): Promise<boolean>;

[dani-mp]

Cool!

I think I will use your version because I find setGenericPassword for a service more semantically correct for my needs than setInternetCredentials for a server.

Thanks!

[Palisand]

So guys... is this a wontfix?

[ronilitman]

This can be very helpful.

[vonovak]

closing, as the question is answered in https://github.com/oblador/react-native-keychain/issues/36#issuecomment-329202738