fix(config-api): audit log filter returns entries beyond the specified end date by pujavs · Pull Request #13920 · JanssenProject/jans (original) (raw)

242-254: ⚠️ Potential issue | 🟠 Major

Validate date parameters before the broad exception handler to prevent returning unfiltered audit logs.

When startDate or endDate are invalid, validateDate() throws BadRequestException from inside isValidlogEntry() (line 313), which is caught by the broad catch (Exception ex) at line 259. This returns the original unfiltered logEntries at line 261, silently bypassing the filter instead of rejecting the bad request.

Validate both date parameters before entering the try block so validation errors propagate to the caller. Also, reuse the parsed DateTimeFormatter instead of creating it for each entry (line 254).

Move validation outside try block and reuse formatter

•    DateTimeFormatter requestDateFormatter = DateTimeFormatter.ofPattern(PARAM_DATE_ISO_OFFSET_DATE_TIME);

•    validateDate(startDate, endDate, requestDateFormatter);

•     List<String> filteredLogEntries = new ArrayList<>();
      try {
          String datePattern = (StringUtils.isNotBlank(getAuditDateFormat()) ? getAuditDateFormat()
                  : AUDIT_FILE_ISO_OFFSET_DATE_TIME);
          log.debug("datePattern:{}", datePattern);

@@

•                if (isValidlogEntry(DateTimeFormatter.ofPattern(PARAM_DATE_ISO_OFFSET_DATE_TIME), startDate, endDate, logEntryLocalDate)) {

•                if (isValidlogEntry(requestDateFormatter, startDate, endDate, logEntryLocalDate)) {
                     filteredLogEntries.add(line);
                 }
             }
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AuditLogResource.java`
around lines 242 - 254, Move validation of startDate and endDate out of the try
block by calling validateDate(startDate) and validateDate(endDate) (or the
existing validateDate method) before entering the try so BadRequestException
from invalid dates propagates to the caller; also create the DateTimeFormatter
once using the computed datePattern (from getAuditDateFormat()/datePattern)
before the loop and pass that single formatter into isValidlogEntry()/getDate
instead of constructing a new formatter for each log entry, and ensure
isValidlogEntry() is invoked with the reused formatter to avoid per-entry
formatter allocation and to preserve proper error handling.

242-253: ⚠️ Potential issue | 🟠 Major

Upgraded deployments with persisted auditLogDateFormat=dd-MM-yyyy will fail timestamp-level filtering.

The upgrade script only sets defaults for missing configuration keys; existing persisted values are not migrated. When old deployments retain the date-only format, the substring extraction at line 250 (line.substring(0, datePattern.length())) will truncate logs written with the new timestamp format, breaking both parsing and end_date filtering.

Additionally, docker-jans-config-api/scripts/upgrade.py line 146 specifies "dd-MM-YYYY" (uppercase YYYY), which is invalid Java date format syntax and should be "dd-MM-yyyy" (lowercase yyyy).

A configuration migration is required to update persisted dd-MM-yyyy entries to dd-MM-yyyy HH:mm:ss.SSS.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@jans-config-api/server/src/main/java/io/jans/configapi/rest/resource/auth/AuditLogResource.java`
around lines 242 - 253, The code assumes persisted audit date patterns always
include time and uses line.substring(0, datePattern.length()), which breaks when
old persisted getAuditDateFormat() values like "dd-MM-yyyy" exist; instead
update the parsing in AuditLogResource to try multiple formatters (first the
full timestamp formatter
AUDIT_FILE_ISO_OFFSET_DATE_TIME/DateTimeFormatter.ofPattern(...), then a
date-only formatter) or detect if the configured pattern is date-only and parse
using that full-length prefix accordingly (use getDate(timestampPart, formatter)
but derive timestampPart length safely based on actual pattern lengths), and add
a migration in the upgrade flow to replace any persisted "dd-MM-YYYY" entries
with the correct "dd-MM-yyyy" and upgrade legacy "dd-MM-yyyy" values to
"dd-MM-yyyy HH:mm:ss.SSS" so stored config matches the new expected timestamp
format; refer to getAuditDateFormat(), AUDIT_FILE_ISO_OFFSET_DATE_TIME,
getDate(), and the upgrade script entry that currently uses "dd-MM-YYYY".