Closed hurradieweltgehtunter closed 1 year ago
@tbsbdr @kulmann fine with 255 char limit?
@tbsbdr @kulmann fine with 255 char limit?
Don't know if that's reasonable for file names. For the rest I agree. Can you find out the character limit on this one:
Rename existing file -> Enter very long filename -> cannot be renamed (500 error)
There seems to be some backend side validation or error on too long file names. Would be nice to know that one before limiting it in the UI.
It is coming from the operating system directly. Depending on which os you run ocis that value can vary. (I guess 255 bytes is common)
Should we check it on server side and return a Bad Request
if the filename is too long? (we can additionally block it on client side too)
@kobergj Bad Request
for too long file names would be nice, thank you 👍 I guess the prio is not super high, so an issue labeled as a junior job could be a good idea as well, right? :-)
I'm against implementing a client side validation for file name lengths though. That would require to have the max chars in e.g. a capability. And I assume that would require manual config via an env var by the sysadmin. Seems unlikely to me that someone will do that.
Will do ui validation on the other cases and add some unit tests.
Hard limit will be max 255 chars
Admin settings:
- Create new Group -> enter very long group name
- Create new user -> enter very long username (First/Lastname and Password accept very long strings but should be limited IMO)
Passwords should never be limited in length IMO. They will not be stored plain text anyway but will be hashed in some way. For user and group display names a limit is a good idea (255 chars is fine, although that still looks ugly in the UI).
Files:
- Create new File -> Enter very long filename
- Create new Folder -> Enter very long folder name
- Rename existing file -> Enter very long filename -> cannot be renamed (500 error), file cannot be deleted afterwards --> Seems to be that frontend stores the new filename but backend does not. Therefore the DELETE requests a filename which does not exist in the backend. Reloading the page shows the old filename again
It's not our decision to make to limit file names in length. Those should be unlimited if possible. See comments above for details. The bug you describe after rename is of course worth investigating.
Sharing link:
- Create sharing link, rename it -> enter very long name: Does not result in 500 error but still should be limited
- Add password to sharing link -> enter very long password: Frontend freezes, request results in 200 OK but error messages appear (Snackbars), password field shows "Password cannot be empty"
I created a server ticket so we don't forget: https://github.com/owncloud/ocis/issues/6049
@rhafer Could you please add information if we have a hard limit for user passwords? As @kulmann mentioned, they actually shouldn't be restricted. But if this is a technical limit I'll add a validator
Actionable items
Needs to be discussed / invastigated:
[x] Sharing link password - 72 chars
Not actionable:
Note Sharing link passwords can't exceed 72bytes, this is a limitation of the used encryption alg in the backend (bcrypt)
This applies on multiple occasions:
Admin settings:
Files:
Sharing link:
Expected behaviour
Input field length should be limited, showing a hint "The group|user|file|... name must not be longer than 255 characters."
Actual behaviour
input field lengths are not limited, entering very long strings results in 500 server error:
Environment general
https://ocis.ocis-wopi.latest.owncloud.works/
Test string i used: