Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Querydsl filtering silently ignores nested property paths since GH-2572

Aperta
  • Qualcosa non va?
#2,579 0 commenti 1 reazione 1 assegnatario Vedi su GitHub

@odrotbohm ci sta già lavorando.

Dal 28/9/2026.

  • #2581 di @lovrovrlec — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
java, spring
Ambito
api, backend

Direzione di ricerca

Inizia da QuerydslAwareRootResourceInformationHandlerMethodArgumentResolver#filterByJacksonVisibility e verifica come jacksonPropertiesLookup e MappedJacksonProperties gestiscono le chiavi della richiesta. Esamina i test esistenti per segmenti singoli che coprono @JsonIgnore e i rinominamenti con @JsonProperty, quindi aggiungi la copertura per percorsi annidati come job.id e segmenti annidati nascosti. Il lavoro è completo quando i percorsi annidati visibili vengono preservati, i segmenti rinominati funzionano e qualsiasi segmento nascosto rifiuta l'intera chiave senza ripristinare il risultato silenzioso non filtrato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
957
Fork
570
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di spring-projects/spring-data-rest

Tutte le issue di spring-projects/spring-data-rest

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.