Hello, really nice project, saved us a pile of code.
Quick context: we're wiring your server into an internal orchestration platform where each task has a logical job/task namespace. Files land in a shared MinIO bucket that already holds other artifacts, so every generated .pptx/.docx/.eml ends up flat in the bucket root next to hundreds of unrelated objects. For us the natural layout would be something like jobs/<job_id>/<task_id>/deck.pptx — same namespace as our other outputs.
I tried smuggling the path into file_name first. That correctly gets scrubbed by sanitize_filename before upload, so slashes vanish and the ids just concatenate into one long filename. Makes sense — you don't want callers pushing ../ into the bucket.
Would you be open to a PR that adds an optional storage_path argument to the create_* tools, kept separate from file_name? Rough shape I had in mind:
-file_name keeps working exactly as it does now (leaf name only, slashes stripped)
-new storage_path: str | None, validated through its own function — allow [A-Za-z0-9_/-], reject .., absolute paths, null bytes, leading /
-upload_file prepends it to the final object key with a / separator
-Fully optional, defaults to empty, no effect on existing calls.
On top of that, a server-wide STORAGE_PATH_PREFIX env would be nice so the host platform can set a default namespace without each caller passing it — but that's secondary, happy to split it into a second PR.
Happy to PR this if the direction works. Tell me if you'd rather do it differently.
Thanks in advance,
Boris Bokun
Hello, really nice project, saved us a pile of code.
Quick context: we're wiring your server into an internal orchestration platform where each task has a logical job/task namespace. Files land in a shared MinIO bucket that already holds other artifacts, so every generated .pptx/.docx/.eml ends up flat in the bucket root next to hundreds of unrelated objects. For us the natural layout would be something like jobs/<job_id>/<task_id>/deck.pptx — same namespace as our other outputs.
I tried smuggling the path into file_name first. That correctly gets scrubbed by sanitize_filename before upload, so slashes vanish and the ids just concatenate into one long filename. Makes sense — you don't want callers pushing ../ into the bucket.
Would you be open to a PR that adds an optional storage_path argument to the create_* tools, kept separate from file_name? Rough shape I had in mind:
-file_name keeps working exactly as it does now (leaf name only, slashes stripped)
-new storage_path: str | None, validated through its own function — allow [A-Za-z0-9_/-], reject .., absolute paths, null bytes, leading /
-upload_file prepends it to the final object key with a / separator
-Fully optional, defaults to empty, no effect on existing calls.
On top of that, a server-wide STORAGE_PATH_PREFIX env would be nice so the host platform can set a default namespace without each caller passing it — but that's secondary, happy to split it into a second PR.
Happy to PR this if the direction works. Tell me if you'd rather do it differently.
Thanks in advance,
Boris Bokun