Closed ghost closed 9 years ago
Michale, which commit solves this issues? In which feature branch?
To this time, i have not resolved this issue.
Ok, than I will remove the "test that" flag
Oh, sorry for that flag.
Is this requirement valid ? Shall we move it into UV/Core issues?
Move it, we should rework the naming, yes. Not from client HTTP infor (multiparf-form-data filename atribute), but from JAR artifactId, parse manifest file etc etc.
Duplicates: https://github.com/UnifiedViews/Core/issues/268
There is possible problem with new DPU filename and directory name. Both filename and directory names on the server are derived from what the client sent in HTTP POST request as filename (which can be really any string!).
Even if we take into account, that this system will not be attacked by any hacker, regular user can hit errors in my opinion.
Consider server running on Windows machine using NTFS. According to http://en.wikipedia.org/wiki/Comparison_of_file_systems#cite_note-note-174-44 the NTFS can handle any character 'except NUL and \ / : * ? " < > |'. Consider client running Linux with ext3, uploading a:-1.1.1.jar. What happens? I don't know, probably error. Will have to test. See
DPUModuleManipulator
class.But there is even more. The
jarDirectory
length limit in database is set to 255 characters. But there is a filesystem (ReiserFS for example) where the filename can be much longer (according to http://en.wikipedia.org/wiki/Comparison_of_file_systems it can be as long as 4096 characters). Even if the server filesystem can handle this, one will probably die on saving to the database, since directory name is derived from filename.I would consider to leave using client sent filename to anything else except file-display-name for the user (and in the database the field would be long enough or the file-display-name would be abbreviated when saving). Let's use another file-real-name (generated random all filesystems safe string) field for the filesystem name (also stored in database).