Fixes #1134. This is the fix I mentioned in my comment there.
Problem. POST /api/v1/library/manual-import returns 500 internal_error for a legitimate file name that contains .. (chapter..mp3, Part 1... Intro.mp3) or that sits in a folder whose name ends in .. The FullPath setter in ManualImportItemDto.cs tested the whole string with value.Contains("..") || value.Contains("./") || value.Contains(".\\") and threw ArgumentException (lines 46-49 on canary). The setter runs while the request body is bound, so the controller never sees the exception, and ListenarrExceptionHandler maps only the application exception types, so ArgumentException falls through to the default 500 (ListenarrExceptionHandler.cs, Map at line 73, default case at line 115).
Change (ManualImportItemDto.cs, two files in total with the new test class):
- The traversal check now splits the path on
/and\and refuses only when a segment is exactly..(line 55)../and.\are no longer tested, becausePath.GetFullPath(line 62) already collapses.segments. - Both checks in the setter (invalid characters at line 46, traversal at line 55) now throw
ApplicationValidationException(manual_import_path_invalid,manual_import_path_traversal). The handler maps that type to 400 (line 75), so a real traversal attempt gets a readable 400 instead of a 500.
Why this loses no protection. The substring check was not the boundary. Each item is normalized with Path.GetFullPath, and ManualImportController.ProcessItem.cs lines 48-63 then reject any file that is not inside the requested path or a configured root folder. That code is untouched. request.Path itself comes from the caller and is only normalized (ManualImportController.cs line 195), so an authenticated caller could already send any absolute path; the old substring check never limited that. A whole .. segment is still refused as defense in depth.
**Te...
Automated Canary build