enable status bar to update immidiately

[Miduo666]

Pull Request Details

This PR enable status bar to update immidiately after entering a correct security key.

Associated Issue

• This PR relates to issue #

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Complete the check-list below to ensure your branch is ready for PR.

• Screenshots included in linked issue #
• Changes adhere to the style and coding guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• Any dependent changes have been merged and published in downstream modules
• The update contains no confidential information
• The update has no duplicated content
• No lint check errors are related to these changes (make prep or flutter analyze lib)
• Integration test dart test output or screenshot included in issue #
• I tested the PR on these devices:
  • Android
  • iOS
  • Linux
  • MacOS
  • Windows
  • Web
• I have identified reviewers
• The PR has been approved by reviewers

Finalising

Once PR discussion is complete and reviewers have approved:

• Merge dev into the this branch
• Resolve any conflicts
• Add a one line summary into the CHANGELOG.md
• Push to the git repository and review
• Merge the PR into dev

[Miduo666]

before:

statusbar1.mp4

after:

statusbar2.mp4

[tonypioneer]

Thanks @Miduo666 for the pull request. I think the original design intention of the status bar security key cached status was as follows:

If a user chooses to cache the security key locally, they do not need to enter it again on each login. If the user chooses not to cache the security key locally, they must enter the security key every time they log in or access encrypted resources. Even after entering it, the key will not be stored locally.

For newly created accounts, the security key is not cached locally by default. Therefore, after the user logs in and enters the security key, the status shown in the bottom-right corner will still display “not cached locally.”

Originally posted by @tonypioneer in #346

[Miduo666]

Understood. So the 'not cached' status is expected even after a successful login if the user didn't explicitly opt for local storage. It’s a bit tricky, but I get the security rationale behind it now. Thanks for pointing that out!

[Miduo666]

However, I think I've found a bug that contradicts this logic. When I refresh the page after a login where the key shouldn't be cached, the status bar incorrectly updates to 'cached locally'. @tonypioneer
bug_report_notepod.zip

[tonypioneer]

However, I think I've found a bug that contradicts this logic. When I refresh the page after a login where the key shouldn't be cached, the status bar incorrectly updates to 'cached locally'. @tonypioneer bug_report_notepod.zip

Thanks for pointing out this issue. I think this is because after we click on the CONTINUE button, the app will use the cached authentication information to log into the app. This may cause the issue. I think we can discuss with @gjwgit about the workflows of security key caching, such as whether the key should be cached after a successful login, and after clicking on the CONTINUE button, whether the key should be cached as well.

[tonypioneer]

Hi @Miduo666, I'll handle this issue at #227.

[gjwgit]

Thanks @tonypioneer for incorporating this into the overall secret key review/update in #227. Thanks @Miduo666 for this fix to be incorproated into #227.

[gjwgit]

Works as advertised. Thanks @Miduo666 - I'll merge this simple fix now.