API Patch Project endpoint silently ignore purl value in object form

[Maxouwell]

Current Behavior

When using the PATCH Project endpoint, if the purl is in object format, it ignores the purl value.
If it is in string format, it is processed.
I suspect the object deserialization of PackageURL is failling and just use null instead.

It may affect other API using the PackageURL object.

Steps to Reproduce

1. Do a curl to /api/v1/project/$UUID with this payload :

{
	"uuid": "$UUID",
	"group": "my.group",
	"purl": {
		"scheme": "pkg",
		"type": "npm",
		"namespace": "my.namespace",
		"name": "my-project",
		"version": "VERSION"
	}
}

2. Request is accepted, group is updated, purl is not
3. Do a curl to /api/v1/project/$UUID with this payload :

{
	"uuid": "$UUID",
	"group": "my.group",
	"purl": "pkg:npm/my.namespace/my-project@VERSION"
}

4. Request is accepted, group and purl are updated

Expected Behavior

Object purl should be accepted, or the swagger should use a string for PackageURL.

Dependency-Track Version

4.8.x

Dependency-Track Distribution

Container Image

Database Server

N/A

Database Server Version

No response

Browser

N/A

Checklist

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

[sebD]

Other affected API endpoints:
PUT /api/v1/project/
POST /api/v1/project/
PUT /api/v1/component/project/{uuid}
POST /api/v1/component/

[valentijnscholten]

I'm interested to know why the json format for purl is useful? It's more common to communicate it in string form?

[nscuro]

Yeah, TBH this seems to be more of an issue with Swagger indicating that purl is an object when in fact it is not.

I don't think there is value in specifying PURLs as object.

Resolving this merely requires adding a @ApiModelProperty(dataType = "string") annotation here:

dependency-track/src/main/java/org/dependencytrack/model/Project.java

Lines 377 to 384 in 8b23434

	@JsonSerialize(using = CustomPackageURLSerializer.class)
	public PackageURL getPurl() {
	try {
	return new PackageURL(purl);
	} catch (MalformedPackageURLException e) {
	return null;
	}
	}

[sebD]

Sure no problems.
I was curious to see how it could be implemented, but if it doesn't serve a useful purpose, I'm happy to remove it and make a more useful change instead.

[sebD]

Here's the result

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.