Jess/388 file discoverability

[jesscmoore]

Pull Request Details

Description

Provides a on permission granted callback with the recipient type, such that the app can do a followup sparlq insert to the app specific index file to append the resource url to the app service account pod index file.

Test with Exper app, branch jess/22_index

This makes public/auth user readable files discoverable.

Related Issues

Issue #388 - supporting apps to have an index file that is appended with the weburl of resources that are shared with public/auth user read access.

And Exper app issue https://github.com/privacyeng/exper/issues/22 - where app has an index file that is appended with the weburl of resources that are shared with public/auth user read access.

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

How To Test?

Checklist

• Screenshots included here/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

• 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

[jesscmoore]

There is a follow on step, that I can also implement in this PR for the below use case:

If the experience owner later decides to share that experience privately, the weburl entry will still stay in the index, it will just no longer be readable. As the file will be re-encrypted and shared privately, and the authuser read access will be revoked.

This last step of revoking authuser read access I need to implement, to stop any user just being served the encrypted experience.

Implementing this in this PR, would make the solidui version more robust.

[jesscmoore]

There is a follow on step, that I can also implement in this PR for the below use case:

If the experience owner later decides to share that experience privately, the weburl entry will still stay in the index, it will just no longer be readable. As the file will be re-encrypted and shared privately, and the authuser read access will be revoked.

This last step of revoking authuser read access I need to implement, to stop any user just being served the encrypted experience.

Implementing this in this PR, would make the solidui version more robust.

Implemented in following solidui and solidpod PRs - with branch name revoke_public