View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 5643 | Composr | core | public | 2024-03-16 15:16 | 2024-09-13 03:32 |
| Reporter | PDStig | Assigned To | PDStig | ||
| Priority | high | Severity | trivial | ||
| Status | assigned | Resolution | open | ||
| Summary | 5643: Add file name restrictions to support Windows | ||||
| Description | Composr should accommodate those running Windows regarding file names and paths. Add restrictions that would normally be allowed on Linux but not Windows, such as but not limited to directories ending in spaces, colons (and possibly other symbols) in file paths, file paths exceeding a certain length, file names above 60 characters, etc. If a UI detects an attempt at doing this, it will warn_exit. If Composr's file integrity scan detects this, it will list so as a new category of bad files (e.g. "incompatible with Windows file systems"). Add this to modularisation as well. | ||||
| Tags | Roadmap: Over the horizon | ||||
| Attach Tags | |||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
Automated message: This issue was created using the Report Issue Wizard on the Composr homesite. |
|
|
Are we saying that form_input_codename is not restrictive enough? |
|
|
I think the limit on codename is 100 characters, correct? If so, then yes, it's not restrictive enough. It needs to be 60 or less for filenames. |
|
|
Right. There's probably additional things as you point out. IIRC there's a regex also for it. |
|
|
Should I proceed that route for codename fields or should I go a different route e.g. only enforcing such on what would be a filename? |
|
|
Hmm, now I think about it tightening up codenames could be problematic, as it would apply standards on what already existed. Same would be the case for filenames too. Probably this should first be approached from a unit testing point of view. What is invalid (why), what is valid, write tests for those cases. Then we can make a call if we need to accept we are tightening up on the existing ID specification or create something new. TBH I would probably rather break some compatibility than layer a lot of extra complexity into the system. Maybe we could consider that field.originalValue is let through codename JS validation somehow, regardless of if it would pass regex validation - and a similar kind of bypass server-side. I do in general feel codenames should be very locked down. |
|
|
I don't know if I follow especially with the JS. I don't see how a testing point of view would help; some of the issues can be caused by user error... e.g. a user uploading a file with a large name. It can also be caused by XML database issues. It uses the values of all primary keys as the filename for the entry. We can't easily restrict these because then that would mean ensuring the total number of characters of all primary key columns do not exceed 60 characters. We could perhaps use a hash instead as it would keep all names under 60 characters, but it would also increase the average filename length which can be an issue given Windows also has a 260 character overall limit on the full path. And it's not easy to tell what it is that way without opening it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-03-16 15:16 | PDStig | Tag Attached: Roadmap: v11 | |
| 2024-03-16 15:16 | PDStig | Assigned To | => user4172 |
| 2024-03-16 15:16 | PDStig | Status | Not Assigned => Assigned |
| 2024-03-16 15:16 | PDStig | Description Updated | |
| 2024-03-30 14:41 | PDStig | Tag Detached: Roadmap: v11 | |
| 2024-03-30 14:41 | PDStig | Tag Attached: Roadmap: Over the horizon | |
| 2024-07-25 22:56 | Chris Graham | Note Added: 0008967 | |
| 2024-07-25 23:27 | PDStig | Note Added: 0008972 | |
| 2024-07-25 23:27 | PDStig | Note Edited: 0008972 | |
| 2024-07-26 01:17 | Chris Graham | Note Added: 0008975 | |
| 2024-07-26 01:32 | PDStig | Note Added: 0008976 | |
| 2024-07-26 17:20 | Chris Graham | Note Added: 0008977 | |
| 2024-09-13 03:32 | PDStig | Note Added: 0009370 |
