Skip to content
This repository has been archived by the owner on Jan 10, 2023. It is now read-only.

[Very Rare] Key Chain is inaccessible/return nil #147

Open
anjananoup opened this issue Mar 19, 2020 · 3 comments
Open

[Very Rare] Key Chain is inaccessible/return nil #147

anjananoup opened this issue Mar 19, 2020 · 3 comments

Comments

@anjananoup
Copy link

I am using SwiftKeychainWrapper in my project. It's working most of the time without any issue. But in very few cases My app is unable to access KeyChain. And after that, no matter what, user restarting app, keyChain is always return nil.

Pod version: 3.4.0

Implementation logic:
On app very first launch (Fresh Install case) (Not update or upgrade case), I remove old keyChain Data Using: KeychainWrapper.standard.removeAllKeys(), thus my app can generate new value and use them.
And other cases I always uses KeychainWrapper.standard.set(.... && KeychainWrapper.standard.string(.... apis to get and set values for my app.

Is there any issue for accessing KeychainWrapper.standard just after removing All old values?
Or this is some king of bug?

@anjananoup anjananoup changed the title [Very Rare] Key Chain is inaccessible on app Reinstall case [Very Rare] Key Chain is inaccessible/return nil Mar 19, 2020
@niteshborad
Copy link

I am having the same issue.
For just one of our clients (around 2000), KeychainWrapper.standard.string(... always returns nil. It is working fine for all other clients.

@kunaltyagi26
Copy link

Hi @jrendel ,
Can you please help with this context as we are also facing this issue with one of our users.

@iceboxi
Copy link

iceboxi commented Apr 15, 2021

I think it's the reason
https://developer.apple.com/documentation/uikit/uiapplication/1622925-isprotecteddataavailable

You should check isprotecteddataavailablebefore access keychain, if it is false, you will get nil value.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants