flutter_secure_storage
flutter_secure_storage copied to clipboard
mogol
`containsKey` always returning true
I've just started using flutter_secure_storage in a new project, for some reason containsKey is returning true for every key value I give it.
In the below image (showing a debug session) you can see that containsKey is returning true even though readAll returns an empty map, and I even try deleting the value associated with the key but containsKey still returns true. This is running on an iOS simulator.
Versions:
- Flutter -
2.5.3 - Dart -
2.14.4 - Xcode -
13.0 - iOS -
15.0 - flutter_secure_storage -
5.0.2
I encountered the same error but found that it only affects the iPad. All of my iPhone test devices worked as expected but the iPad always returns true.
We make an additional check on the value of the key to work around this issue - if the key is reported to be there, we additionally check if it is not null and not empty. This feels wrong but at least people can use our app again... 🙃
@ToniTornado , we just removed the usage of containsKey. Since read returns a nullable value, we just check to see if it's null when we try and read it rather than first check if it's there. This bug caused a hiccup in our iOS release, but we've worked around it now. @mogol , please review this case ^.
@dustin-graham For sure, that should be enough. I checked my code again and I also just read the value and check for null. In some rare case I got an empty string so I am checking for that too. But this might be specific to my app. I also checked the implementation of containsKey in this plugin for a possible fix but I was not able to understand that keychain ObjC code that is bridging to some other lib.... 🙈
I got the same issue contains key always return true.
I try to testing with multiple version.
I have try to check :
var containsEncryptionKey = await secureStorage.containsKey(key:keyName); // Alway return true. if (!containsEncryptionKey) { var keyGenerate = Hive.generateSecureKey(); await secureStorage.write(key: keyName, value: base64UrlEncode(keyGenerate)); } //var data = await secureStorage.read(key: keyName); // nullable var data = await secureStorage.readAll(); // length ==0 if (data != null && data.length == 0) { // come true. }
flutter_secure_storage - 5.0.0 & 5.0.1 & 5.0.2 Flutter - 2.8.1 Dart - 2.15.1 Xcode - 13.2 iOS - 15.2
Same issue here, using latest pub version :(
We've also removed containsKey usage and replace it by a null check on read.
flutter doctor ─╯
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.8.1, on macOS 12.1 21C52 darwin-arm, locale fr-FR)
[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 13.2.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2020.3)
[✓] Android Studio (version 2020.3)
[✓] VS Code (version 1.63.2)
[✓] Connected device (3 available)
• No issues found!
This is a major bug for such a big package. @juliansteenbakker or @mogol can we timeline on when this can be fixed?
same error here! affecting all my iOS Devices. while android works well.
we can overcome this by downgrading to this version : flutter_secure_storage: ^4.2.1
This has caused really nasty bug with our iOS releases, took me few hours to find this out since the problem occurred only on devices that never had previous builds.
I can confirm v4 does not have this problem. Also replaced containsKey with check on null value by using read.
downgrading to this version :
flutter_secure_storage: ^4.2.1
Same here, our development-team choose the same option - too bad, since we can't have an the other improvements which came with upgrade to version > 5.x.x
Same issue here. Guys, this bug was reported Nov. last year. Has it been solved?
I'm sure if it had been solved there would be a bug fix release. Last I checked, open source maintainers weren't paid for their efforts, so the demanding tone is most likely not going to get the results you're looking for.
I am aware of this issue as well as some other issues with this package. I'm trying to free up some time to work on this but i'm working on more packages that just this one. Like I said in other issues, I encourage people to try and fix it them self and i am very much open for PR's that could fix this problem.
Seems like this bug has been introduced with the version 5.0.0-beta.5 with the new containsKey method.
As a workaround you can go back to the previous implementation using:
(await _flutterSecureStorage.read(key: 'key')) != null
instead of
await _flutterSecureStorage.containsKey(key: 'key')
This bug is really critical. Please note it inside the readme this method is faulty.
@juliansteenbakker juliansteenbakker mentioned this issue on 24 Aug https://github.com/mogol/flutter_secure_storage/pull/437
@juliansteenbakker Do you have any indication when this will be merged into the master branch?
Sorry for the delay, i've been busy with moving to a new house and last week i've been hit by covid. I think i finished all the code but i did not have any time to test it.
If someone has time to test my code i'd be very happy. After some verification i can merge and release a new version.
I have released v6.1.0-beta.1 which probably fixes this issue. Can you please check, and if there is any error comment on this issue?
Hi @juliansteenbakker - I've tried the beta - it does not resolve the issue.
As a workaround you can go back to the previous implementation using:
(await _flutterSecureStorage.read(key: 'key')) != nullinstead of
await _flutterSecureStorage.containsKey(key: 'key')
At least this works
Well, I'm glad I searched and found this. I ended up switching to a null check of .read() and got some code working. Then ran into the same issue again further down the execution sequence, and felt it was an issue. Found this and it's good to know for sure!
I agree this should NOT be an issue for such an important and large library. Null checks and empty checks are sloppy, can this be fixed? Believe me, I would help if I was experienced enough to do so... Up to you geniuses, someone get this puppy fixed ;)
I suppose the issue is not one of writing the fix, it's integrating the fix into the project. I fully understand why the author of this library hasn't gotten around to doing so - I have projects of my own that have fallen into a similar state of disrepair. @juliansteenbakker - any way we can collectively motivate you? Github has sponsorship...
I understand this is still a problem, and it is not that i don't want to fix this, but rather i have some other plugins that require more work right now.
@Adam-Langley ofcourse your welcome to sponsor me, but for me its a problem of time and not motivation/money. I have a fulltime job besides working on these plugins and the december months are more busy than others.
As always im open for PR's with a fix. I'll also take another look into this tomorrow to see if i can come up with anything else.
Hey @juliansteenbakker - absolutely see your position. Not criticising at all. I wonder if perhaps just integrating the pure-dart workaround that several ppl have put in this thread - into your wrapper code, until you have time to write your preferred approach (which I assume is more complex, and involves native code)? That way, you get to put it to bed for a little while, and it will tripping up the newbies?
Ill see if i can try and fix it on the native side. If not, ill implement this workaround as a quick fix.
Thanks @juliansteenbakker - that would be awesome. Thank you for giving it a try - can't ask for much more than that! Throwing some appreciation your way :)
It turned out the sharedPreference instance was created multiple times in Android. This was causing lots of problems with not only containsKey, but also trying to read the value using the key. I have fixed these issues, together with containsKey problems on macOS in version 7.0.0. Please check it out and let me know if this fixes the issues 😄