feat: add middleware class

[athith-g]

I created an outline of what the middleware class might look like. Are there any problems/is there anything I should keep in mind before hashing the details out? @jvkersch @uniqueg

Summary by Sourcery

Add a CryptMiddleware class to manage Crypt4GH file inputs, including setting original input paths, checking volumes, modifying executor and output paths, and adding a decryption executor to the request.

New Features:

• Introduce a new CryptMiddleware class to handle Crypt4GH file inputs in Flask applications.

[uniqueg]

Looked just at the schema - looks good to me! Two questions:

• What about outputs? I reckon it's trivial, because they wouldn't change compared to the original executors. But perhaps would be good to include them in your nice overview schema, just to highlight that.
• What if /vol/crypt and/or /vol/crypt/file.{txt,c4gh} are listed as volumes or inputs? What is the expected behavior for such conflicts in your opinion?

[athith-g]

I assumed that the outputs would remain the same but now that you mention it there could be a scenario where a script modifies a file in place, which means the input path might appear in the output. I'll check for that as well thanks.

I was thinking of making /vol/crypt a reserved file path, so I'd throw an error if any path started with /vol/crypt or if it appeared in the volume list.

[sourcery-ai]

Reviewer's Guide by Sourcery

This pull request introduces a new CryptMiddleware class in the crypt4gh_middleware/middleware.py file. The class is designed to handle Crypt4GH file inputs in a Flask application. It modifies incoming requests to decrypt Crypt4GH encrypted files before they are processed by the main application logic. The middleware adds a decryption executor, changes file paths in the request, and performs various checks to ensure proper handling of encrypted files.

File-Level Changes

Files	Changes
crypt4gh_middleware/middleware.py	Implemented a CryptMiddleware class with methods to modify incoming requests for Crypt4GH file handling
crypt4gh_middleware/middleware.py	Added a method to insert a decryption executor at the beginning of the executors list
crypt4gh_middleware/middleware.py	Implemented path modification methods for executors and outputs to use decrypted files
crypt4gh_middleware/middleware.py	Added validation checks for volumes and input paths to prevent conflicts with the decryption output directory
crypt4gh_middleware/middleware.py	Created an apply_middleware method to orchestrate the request modification process

---

Tips

• Trigger a new Sourcery review by commenting @sourcery-ai review on the pull request.
• Continue your discussion with Sourcery by replying directly to review comments.
• You can change your review settings at any time by accessing your dashboard:
  • Enable or disable the Sourcery-generated pull request summary or reviewer's guide;
  • Change the review language;
• You can always contact us if you have any questions or feedback.

[sourcery-ai]

Hey @athith-g - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider using Path objects consistently throughout the class for more robust path handling, especially in methods like _change_executor_paths and _change_output_paths.
• The middleware currently uses hardcoded values for the image name and output directory. Consider making these configurable through environment variables or constructor parameters for increased flexibility.

Here's what I looked at during the review

• 🟡 General issues: 4 issues found
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.}

[jvkersch]

Two minor questions.

[uniqueg]

Looks good to me and I think we can merge.

However, one comment for consideration for a possible change in the future: Could VOLUME_PATH be set randomly (e.g., via the tempfile module) to something less guessable/obvious? Someone who gains access to the filesystem attached to the TES service might have a slightly harder finding interesting data if decrypted data isn't always written to the same place.

[athith-g]

@uniqueg Yeah that's a good idea I can do that in this pull request.