dotCMS / dotCMS/core

bug: Push Publishing Job Management API — 4 issues in error handling and input validation

Open
#34,862 4 comments 0 reactions 1 assignee View on GitHub

@hassandotcms is already working on this.

Since Mar 5, 2026.

Dominant language
Java
Stars
970
Forks
486
Avg merge
3d 33m
Merged PRs (30d)
170

Description

Summary

During exploratory testing of the Publishing Push publishing job management REST endpoints (/api/v1/publishing/*), 4 issues were identified related to error handling consistency, input validation, and error message quality.

Issues Found

1. GET /api/v1/publishing/{bundleId} — XSS characters in path return Tomcat HTML instead of JSON

Severity: Low
Endpoint: GET /api/v1/publishing/{bundleId}

When the bundleId path parameter contains characters like <script>, Tomcat rejects the request at the container level and returns an HTML 400 page instead of a JSON error response. All other error cases for this endpoint return well-formed JSON.

Steps to reproduce:

curl -s "http://localhost:7070/api/v1/publishing/bundle%3Cscript%3E" \
  -H "Authorization: Bearer $TOKEN"

Expected: JSON response {"error": "dotcms.api.error.bad_request: ..."}
Actual: Tomcat HTML 400 page — <html><title>HTTP Status 400 - Bad Request</title>...

2. POST /api/v1/publishing/retry — Invalid deliveryStrategy exposes internal Java class name

Severity: Low
Endpoint: POST /api/v1/publishing/retry

When an invalid deliveryStrategy value is submitted, the error message exposes the internal Java class name com.dotcms.publishing.PublisherConfig$DeliveryStrategy. This is inconsistent with other validation errors on this API which return clean, user-friendly messages.

Steps to reproduce:

curl -s -X POST "http://localhost:7070/api/v1/publishing/retry" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"bundleIds":["some-bundle"],"deliveryStrategy":"INVALID_STRATEGY"}'

Actual response:

{"message":"Can not construct instance from value 'INVALID_STRATEGY': not a valid class com.dotcms.publishing.PublisherConfig$DeliveryStrategy value"}

Expected response (consistent with other endpoints):

{"error":"dotcms.api.error.bad_request: Invalid deliveryStrategy: 'INVALID_STRATEGY'. Valid values: ALL_ENDPOINTS, FAILED_ENDPOINTS"}
3. GET /api/v1/publishing — Out-of-range page/per_page values are silently clamped instead of returning 400

Severity: Info
Endpoint: GET /api/v1/publishing

The OpenAPI spec states valid range for per_page is 1-500 and page starts from 1. However, out-of-range values are silently clamped to the nearest valid value and a 200 is returned. The spec documents a 400 for "pagination out of range".

Input Expected (per spec) Actual behavior
per_page=0 400 200, clamped to perPage: 1
per_page=-1 400 200, clamped to perPage: 1
per_page=501 400 200, clamped to perPage: 500
page=0 400 200, clamped to currentPage: 1

Either the spec should be updated to document the clamping behavior, or the endpoint should return 400 for out-of-range values.

4. POST /api/v1/publishing/push/{bundleId} — Invalid date format bypasses validation (bundle lookup runs first)

Severity: Info
Endpoint: POST /api/v1/publishing/push/{bundleId}

When publishDate contains an invalid format (e.g. "2025/03/15 14:30:00" instead of ISO 8601), the endpoint returns 404 (bundle not found) instead of 400 (invalid date format). This happens because the bundle DB lookup executes before the date format is validated.

Steps to reproduce:

curl -s -X POST "http://localhost:7070/api/v1/publishing/push/nonexistent-bundle" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"operation":"publish","filterKey":"ForcePush.yml","environments":["env-id"],"publishDate":"2025/03/15 14:30:00"}'

Expected: 400 — invalid date format
Actual: 404 — bundle not found (date validation never reached)

Date format validation should occur before the bundle DB lookup to provide accurate feedback.

Test Environment

  • Endpoints tested: GET /api/v1/publishing, GET/DELETE /api/v1/publishing/{bundleId}, POST /api/v1/publishing/push/{bundleId}, POST /api/v1/publishing/retry, DELETE /api/v1/publishing/purge
  • Total tests run: 85
  • Pass: 84 | Fail: 1 (issue #1 above; issues #2-4 are behavioral observations)

Acceptance Criteria

  • GET /api/v1/publishing/{bundleId} returns a JSON error response for all invalid bundleId inputs, including those with special characters
  • POST /api/v1/publishing/retry returns a clean, user-friendly error message for invalid deliveryStrategy values without exposing internal Java class names
  • GET /api/v1/publishing behavior for out-of-range page/per_page is either documented (clamping) or enforced (400) — spec and implementation agree
  • POST /api/v1/publishing/push/{bundleId} validates publishDate/expireDate format before performing the bundle DB lookup

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.