Feature/deep links

[TrevorBurgoyne]

S3 Deep Links

What?

• Added intercept_s3_protocol as a top-level option in the config, which allows the user to specify which components should be allowed to handle redirects from s3:// links.
• When enabled, navigating to an s3:// link in a browser will automatically prompt the user to open the link in QASM. Depending on the active screen in the app, the link will then be passed to the component and loaded
• For grid and multiclassgrid, links will be loaded as labels if they end in .json, else they will try and be automatically loaded as an image directory.
• For imagelabeler, links will be loaded as a label if they end in .json, an image if they end in .png or .jpg, or will prompt the user to select whether to load a folder as an image directory or annotation directory.
• To test, add the following to the demo config:

  "intercept_s3_protocol": [
  "grid",
  "multiclassgrid",
  "imagelabeler"
  ],

  and try navigating to a link like s3://qasm-demo/grid-data/demo-1/images/

• Also added some package.json fields bc I was sick of electron-builder complaining

  Why?

• @joshua-dean suggested the feature and pointed me to this in the electron docs.
• This is one step towards having an upgraded, standalone S3 Browser component that can load an s3 link, and also provide basic functionality like downloading, previewing, uploading, etc.

  Checks:

• [x] Merged latest master
• [x] Tested relevant changes in all backend modes [local, s3]
• [x] Tested relevant changes in all frontend modes [locally, .exe, static site]
• [x] Ran npm run qasm-push -- --config_path "./default-config.json" to update the Demo site
• [x] Updated README.md (if needed)
• [x] Changed version number in react-frontend/package.json (if needed)

  Breaking Changes

  To ensure that the protocol is properly removed on uninstall, a custom uninstall script had to be added. This seems to cause some collisions when trying to run qasm-build for an app that is already installed locally, and so existing apps with the same name must first be properly uninstalled using the app's uninstaller.

[joshua-dean]

There seems to be some access constraint with terraform init regarding the S3 bucket where the actual terraform configuration resides, preventing me from testing this without access (on my current machine anyways). I'll take a look at this later tonight. This might be solved by adding some base64 string to the bucket names (to avoid collisions) and some logic to check whether QASM buckets exist in the account of the deployer. It also could be a skill issue on my part.

It is probably worth looking into some interoperability (for both testing and deployment) between locally available and assumed AWS credentials. Either a config specification for AWS_PROFILE or a "setup GUI" to do so would be handy to make sure things are deployed in the right spot, and make pure-standalone applications easier to test. (By pure-standalone, I mean applications that access only public resources or the necessary credentials are bundled in deployment, e.g. the demo build).