-
-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: BAD_DECRYPT Exception on invalid cipher #1730
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1730 +/- ##
==========================================
- Coverage 8.86% 8.26% -0.60%
==========================================
Files 161 165 +4
Lines 6623 7148 +525
==========================================
+ Hits 587 591 +4
- Misses 6036 6557 +521
Continue to review full report at Codecov.
|
try { | ||
userId = await DaoSecuredString.get(_USER_ID); | ||
password = await DaoSecuredString.get(_PASSWORD); | ||
} on PlatformException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a comment here on the kind of exception it was (SSL related, possibly on old devices ?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @M123-dev!
I think it's not fair to just bypass the exception. What are we supposed to do with "less fortunate" users? Shouldn't we store the user/password in DaoString
instead, as a fallback? Shouldn't we have detected that issue previously when the user stored the user/password: it probably didn't work either at that moment.
Any idea of the root cause of this crash? (there's no "issue" by the way).
Heyyy @monsieurtanuki, the API used in the secure storage package was introduced in android 4.3 (Now around 10 years old), I think we have a lot more other problems on these version. The error occured to me when I had the app installed via the PlayStore and then installed it via USB Debugging from my PC (for running in debug mode). After that it fails what's good in terms of security. But if we know that such a case meight happen we don't need to throw a exeption but just handle it. But because it's a security and not feature related bug there is no way of knowing it in advance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @M123-dev!
I didn't know what you mentioned was possible; when I develop in Android/java the app refuses to install a debug apk on a release apk and so on. That doesn't work that way with flutter, fair enough.
The general idea is good: in those strange cases just display "you have been logged out", remove the credentials and that's it.
The timing is not good though: adding a Scaffold
(for the Snackbar
) is not a good solution, as we've already experienced bugs because of embedded Scaffold
s. Please call the Snackbar
somewhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@M123-dev Not convinced either by your latest change. That's tricky...
Let's say that only naughty boys like you may experience that "logged out" exception: what about just printing a log? And moving the code back to main.dart
?
Sure @monsieurtanuki |
packages/smooth_app/lib/main.dart
Outdated
@@ -227,6 +227,8 @@ class SmoothAppGetLanguage extends StatelessWidget { | |||
final LocalDatabase _localDatabase = context.read<LocalDatabase>(); | |||
AnalyticsHelper.trackStart(_localDatabase, context); | |||
|
|||
context.read<UserManagementProvider>().mountCredentials(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not await
? Btw as it's in the init part and we do that only once, do we have to notify the listeners in mountCredentials
? I don't think so, as it's dangerous to notify while building a Widget
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no await intended, since the credentials are not needed directly after start, this can run when there is time for that. Because of that that little more efford with the provider
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not convinced. All we do in mountCredentials
is get the credentials from the dao and put them in static. Quick and easy.
OK, technically you are allowed not to wait until it finishes and use the provider for the refresh, but:
- hey, it's init time, let's init once and for all
- the notifylistener will trigger a display refresh just because you didn't want to spend 20 milliseconds
await
ing - not everything we do is strictly needed at init time - we also set the query country, which is useless as we haven't queried anything yet
- btw
mountCredentials
could be called much earlier, in_init1
or_init2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just applied your suggestions, my first approach was to completely remove the provider, but looking into it again we should keep it to properly reflect logins from for example the login card.
packages/smooth_app/lib/data_models/user_management_provider.dart
Outdated
Show resolved
Hide resolved
Co-authored-by: monsieurtanuki <fabrice_fontaine@hotmail.com>
@monsieurtanuki just saw the stats on Sentry, looks like I'm really the only one with the problem 😆 |
What