[FR]: Allow using a request id with slashes representing a path

[HolzmanoLagrene]

What is the feature you are proposing?

Problem

When uploading evidence I usually do this using a path as Ticket ID in order to have everything structured on disk. This looks e.g. like this: Case123/Evidence1/data.E01. This then results in a request ID with e.g. the following structure Case123/Evidence1/ab45345fe2....

This works up to the point where I want to query for this using the /api/request/{request_id} endpoint: As this endpoint expects a pure string, my request ID Case123/Evidence1/ab45345fe2... makes the API interpret it as an endpoint that doesnt exist and i get a 404.

Solution

FastApi allows to specify a string parameter to allow slashes as stated here. My suggestion therefore is to do the following:

Change this line

https://github.com/google/turbinia/blob/0905899ca7a2dc8256371b126945b2f550d00020/turbinia/api/routes/request.py#L63 to this

@router.get('/report/{request_id:path}')

And this line

https://github.com/google/turbinia/blob/0905899ca7a2dc8256371b126945b2f550d00020/turbinia/api/routes/request.py#L89

to this

@router.get('/{request_id:path}')

What would this feature improve or what problem would it solve?

This would change nothing of the current behaviour but allow to pass strings that are containing slashes as to allow the workflow described above.

What alternatives have you considered?

This is a minimal change with a small impact. So none.

[aarontp]

Hi @HolzmanoLagrene, thanks for the report.

Is the goal here to be able to support having sub-directories for uploaded data so that it is better structured on disk to match the source structure?

If I'm understanding the issue correctly, I'm not sure that using the ticket ID to implicitly create sub-directories is a good idea as there are probably other places across the code base that make assumptions about the directory structure, and it may even cause security issues with path traversal bugs. If you could give me a bit more info on the goal here maybe we can find a different solution for this.

[HolzmanoLagrene]

Hi @aarontp

Yes that is exactly the point: I need to be able to generate a little structure on my evidence as well as on my outputs. And as the documentation states ticket_id (str): ID of the ticket, which will be the name of the folder where the evidence will be savedi was assuming, that this behaviour was intended.

When creating turbinia requests, i get the request_id, a string created using the path of the evidence and the id of the evidence. This all works fine until you try to query the api with this request id, due to the before-mentioned problems.

I totally see your point! But i am using a path of some depth e.g. /path/to/evidence/ as ticket_id for a long time and i never ran into any issues! Also the proposed tweak did not break anything so far for me. But i agree, that you would ideally be able to specify the target location of the evidence with a precise parameter.