Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Querydsl filtering silently ignores nested property paths since GH-2572

Đang mở
  • Có gì không ổn?
#2,579 0 bình luận 1 reaction 1 người được giao Xem trên GitHub

@odrotbohm đang làm issue này rồi.

Từ ngày 28/9/2026.

  • #2581 của @lovrovrlec — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
76/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
java, spring
Lĩnh vực
api, backend

Hướng nghiên cứu

Bắt đầu tại QuerydslAwareRootResourceInformationHandlerMethodArgumentResolver#filterByJacksonVisibility và kiểm tra cách jacksonPropertiesLookup và MappedJacksonProperties xử lý các khóa request. Xem lại các test hiện có cho một segment, bao phủ @JsonIgnore và việc đổi tên bằng @JsonProperty, sau đó bổ sung coverage cho các path lồng nhau như job.id và các segment lồng nhau bị ẩn. Hoàn tất có nghĩa là các path lồng nhau hiển thị được giữ nguyên, các segment đã đổi tên hoạt động, và bất kỳ segment bị ẩn nào cũng từ chối toàn bộ key mà không khôi phục lại kết quả không lọc một cách im lặng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

type: regression

spring-data-rest 5.0.6 (and the sibling GH-2572 backports on the other maintenance lines) drops every
nested query parameter, e.g. ?job.id=1, ?address.city=Paris.

The predicate ends up empty and the endpoint silently returns all rows instead of the filtered set.
Nested paths worked in 5.0.5 and are still fully supported by
QuerydslPredicateBuilder (bindings.getPropertyPath resolves dotted paths).

Cause:
QuerydslAwareRootResourceInformationHandlerMethodArgumentResolver#filterByJacksonVisibility
looks up the entire request-parameter key in MappedJacksonProperties#fieldNameToProperty, which is
keyed by TOP-LEVEL Jackson field names only:

PersistentProperty<?> property = properties.getPersistentProperty(entry.getKey()); // "job.id"
if (property != null) { filtered.put(property.getName(), entry.getValue()); }

"job.id" is never a key, so the parameter is discarded regardless of visibility.
This affects associations that are fully exposed:

in our case the property has no @JsonIgnore and no @RestResource(exported = false),
and getPersistentProperty("job") resolves fine, while getPersistentProperty("job.id") returns null.

The two tests added in 3dc76b88 cover single-segment keys only (@JsonIgnore and @JsonProperty renames),
which is presumably why the regression went unnoticed.

Impact: silent — no 400, no warning. A multi-tenant reporting endpoint filtered by ?job.id=
returns the tenant's entire history instead of one job's rows.

Suggested fix — resolve the key segment by segment, rejecting it if ANY segment is hidden.
This keeps the GH-2572 guarantee (and extends it to nested levels) while restoring nested paths:

private @Nullable String resolvePath(Class<?> type, String key) {
    StringBuilder resolved = new StringBuilder();
    Class<?> currentType = type;
    for (String segment : DOT.split(key)) {
        MappedJacksonProperties properties = jacksonPropertiesLookup.apply(currentType);
        if (properties == null) return null;
        PersistentProperty<?> property = properties.getPersistentProperty(segment);
        if (property == null) return null;              // hidden at this level -> reject whole key
        if (!resolved.isEmpty()) resolved.append(".");
        resolved.append(property.getName());            // honours @JsonProperty renames per segment
        currentType = property.getActualType();
    }
    return resolved.toString();
}

The resolver already holds jacksonPropertiesLookup as Function<Class<?>, MappedJacksonProperties>, so
no new wiring is needed. Happy to submit a PR with a nested-path test alongside the existing ones.

Ngôn ngữ chính
Java
Star
957
Fork
570
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của spring-projects/spring-data-rest

Tất cả issue của spring-projects/spring-data-rest

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.