Missing length validation for text input leading to internal server error

[KS-DR]

Current Behavior

When creating or updating project attributes like the description with input too long for the DB fields, an internal server error (HTTP status 500) occurs and the user is not informed about what went wrong.

Steps to Reproduce

1. Go to {Your-DT-URL}/projects
2. Click on "+ Create Project"
3. As description type more than 255 characters, e.g. "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
4. Fill out the remaing mandatory fields
5. Get HTTP status 500

Expected Behavior

1. Input fields should have the correct maxlength HTML attribute, preventing the user from typing too much text that can't be saved.
2. The backend should validate the length of input before processing it to prevent internal server errors.
3. The user should get informed if he provided unvalid input so that he can change it accordingly.

Dependency-Track Version

4.12.1

Dependency-Track Distribution

Container Image

Database Server

PostgreSQL

Database Server Version

14.7

Browser

Microsoft Edge

Checklist

• [x] I have read and understand the contributing guidelines
• [x] I have checked the existing issues for whether this defect was already reported

[nscuro]

Going to move this to v4.13. To really resolve this, input fields in the UI need indicators as to how many characters are allowed. We also need to ensure forms can't even be submitted if any of the inputs are in an invalid state.

[msymons]

@KS-DR , having to re-assign this to v4.14.0 milestone in order that v4.13.0 be released without further delay.

On the positive side, the v4.13.0 release will contain a lot of useful new functionality.

[snieguu]

I have added validation on the API side for the case from the issue. The frontend-side validation is just a cosmetic (fail-fast) feature and is not relevant from a security perspective. There are many places that require similar validation. I think that, along with adding similar annotations, we should also create a fallback mechanism that will handle specific exceptions and translate them into appropriate HTTP statuses.