gwplatform:release_notes

Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

Link a questa pagina di confronto

Entrambe le parti precedenti la revisione Revisione precedente
gwplatform:release_notes [2026/10/27 17:43]
giorgio.scali
gwplatform:release_notes [2026/10/27 17:46] (versione attuale)
giorgio.scali
Linea 172: Linea 172:
   * dbWindowList/​windowChoice:​ il filtro sulla griglia del popup non funzionava per nessuna colonna di columnsViews/​columnsLabels tranne la prima, tornando l'​elenco non filtrato senza segnalare errori. Causa: WindowChoiceController#​dbWindowList splitta columnsLabels/​columnsViews sulla virgola senza fare trim() dei singoli valori (a differenza di fieldToStore/​fieldToShow,​ già trimmati esplicitamente qualche riga più sotto); una configurazione con uno spazio dopo la virgola (es. "​name_building,​ cod_building,​ address"​),​ abitudine comune di chi scrive l'XML a mano, produceva un columnName con spazio iniziale (" cod_building"​) inviato al server. Il controllo esistente in GwClassListService.discardFiltersNotInQueryTargetTable() (introdotto con l'​issue #1894) confronta columnName contro le colonne reali della tabella senza trim, non trova match e scarta silenziosamente il filtro invece di segnalare l'​anomalia. Risolto trimmando i valori sia in WindowChoiceController (alla fonte) sia, come difesa aggiuntiva, in discardFiltersNotInQueryTargetTable() (issue #1899)   * dbWindowList/​windowChoice:​ il filtro sulla griglia del popup non funzionava per nessuna colonna di columnsViews/​columnsLabels tranne la prima, tornando l'​elenco non filtrato senza segnalare errori. Causa: WindowChoiceController#​dbWindowList splitta columnsLabels/​columnsViews sulla virgola senza fare trim() dei singoli valori (a differenza di fieldToStore/​fieldToShow,​ già trimmati esplicitamente qualche riga più sotto); una configurazione con uno spazio dopo la virgola (es. "​name_building,​ cod_building,​ address"​),​ abitudine comune di chi scrive l'XML a mano, produceva un columnName con spazio iniziale (" cod_building"​) inviato al server. Il controllo esistente in GwClassListService.discardFiltersNotInQueryTargetTable() (introdotto con l'​issue #1894) confronta columnName contro le colonne reali della tabella senza trim, non trova match e scarta silenziosamente il filtro invece di segnalare l'​anomalia. Risolto trimmando i valori sia in WindowChoiceController (alla fonte) sia, come difesa aggiuntiva, in discardFiltersNotInQueryTargetTable() (issue #1899)
   * report html su floatingPane non visualizza toolbar V H (issue #1897)   * report html su floatingPane non visualizza toolbar V H (issue #1897)
-  * labelValueJsonWidget non visualizza alcun input della form con valori date null o '' ​(issue #1896)+  * labelValueJsonWidget non visualizza alcun input della form con valori date null o "" ​(issue #1896)
   * aggiornata la libreria Netty (4.1.135.Final -> 4.1.138.Final) per CVE-2026-75595:​ un flaw in SslClientHelloHandler#​decode controllava l'​offset sbagliato leggendo l'​header di handshake TLS, permettendo a un ClientHello frammentato su più record di selezionare l'​SslContext di default invece di quello specifico per SNI; nei deployment dove il mutual TLS per-SNI (clientAuth=REQUIRE) è l'​unico controllo di autenticazione,​ un attaccante remoto non autenticato poteva così bypassarlo. L'​aggiornamento risolve anche gli altri difetti Netty emersi sullo stesso export SCA (CVE-2026-62243,​ CVE-2026-75596 e diversi request smuggling HTTP/queue growth DoS in netty-codec-http) fissando la versione fino all'​ultima disponibile della linea 4.1.x, ABI-compatibile e Java 8 (pom.xml, dependencyManagement io.netty:​*). Il fix nel pom.xml root da solo non bastava a coprire il war effettivamente deployato (space.war):​ gw-webapp-template non ha <​parent>​geowebframework</​parent>​ e non eredita quindi quel dependencyManagement,​ per cui la mediazione Maven "​nearest wins" continuava a risolvere una versione ben più vecchia (4.1.116.Final) dal grafo transitivo di gw-webclient -> firebase-admin. Aggiunto lo stesso dependencyManagement io.netty:* anche in gw-webapp-template/​pom.xml (issue #1825)   * aggiornata la libreria Netty (4.1.135.Final -> 4.1.138.Final) per CVE-2026-75595:​ un flaw in SslClientHelloHandler#​decode controllava l'​offset sbagliato leggendo l'​header di handshake TLS, permettendo a un ClientHello frammentato su più record di selezionare l'​SslContext di default invece di quello specifico per SNI; nei deployment dove il mutual TLS per-SNI (clientAuth=REQUIRE) è l'​unico controllo di autenticazione,​ un attaccante remoto non autenticato poteva così bypassarlo. L'​aggiornamento risolve anche gli altri difetti Netty emersi sullo stesso export SCA (CVE-2026-62243,​ CVE-2026-75596 e diversi request smuggling HTTP/queue growth DoS in netty-codec-http) fissando la versione fino all'​ultima disponibile della linea 4.1.x, ABI-compatibile e Java 8 (pom.xml, dependencyManagement io.netty:​*). Il fix nel pom.xml root da solo non bastava a coprire il war effettivamente deployato (space.war):​ gw-webapp-template non ha <​parent>​geowebframework</​parent>​ e non eredita quindi quel dependencyManagement,​ per cui la mediazione Maven "​nearest wins" continuava a risolvere una versione ben più vecchia (4.1.116.Final) dal grafo transitivo di gw-webclient -> firebase-admin. Aggiunto lo stesso dependencyManagement io.netty:* anche in gw-webapp-template/​pom.xml (issue #1825)
   * dbWindowList/​windowChoice con query libera configurata su una tabella priva di relazione con la classe di partenza (es. picker "​Immobile"​ su gwd_building aperto da una scheda/​lista di un'​altra classe): se nella classe di partenza risultava attivo un filtro su un attributo omonimo (stesso column_name,​ classe diversa), quel filtro veniva comunque applicato alla query libera del popup, causando un errore SQL "​colonna inesistente"​. Causa: i filtri per dbWindowList/​windowChoice vengono risolti per attributeGwid e applicati sempre senza alias di tabella (QueryBuilder.queryBuilderDbWindowListService forza tableIndex=null),​ quindi un filtro risolto su una colonna omonima di un'​altra classe passava senza controlli; la difesa introdotta con l'​issue #1844 non copre questo caso perché richiede una query.getGwClass() valorizzata,​ assente nel flusso dbWindowList/​windowChoice. Risolto in GwClassListService.buildList():​ discardFiltersNotInQueryTargetTable() scarta ora i filtri la cui colonna non esiste realmente nella tabella target della query libera (dedotta dalla queryString e verificata con CatalogService) (issue #1894)   * dbWindowList/​windowChoice con query libera configurata su una tabella priva di relazione con la classe di partenza (es. picker "​Immobile"​ su gwd_building aperto da una scheda/​lista di un'​altra classe): se nella classe di partenza risultava attivo un filtro su un attributo omonimo (stesso column_name,​ classe diversa), quel filtro veniva comunque applicato alla query libera del popup, causando un errore SQL "​colonna inesistente"​. Causa: i filtri per dbWindowList/​windowChoice vengono risolti per attributeGwid e applicati sempre senza alias di tabella (QueryBuilder.queryBuilderDbWindowListService forza tableIndex=null),​ quindi un filtro risolto su una colonna omonima di un'​altra classe passava senza controlli; la difesa introdotta con l'​issue #1844 non copre questo caso perché richiede una query.getGwClass() valorizzata,​ assente nel flusso dbWindowList/​windowChoice. Risolto in GwClassListService.buildList():​ discardFiltersNotInQueryTargetTable() scarta ora i filtri la cui colonna non esiste realmente nella tabella target della query libera (dedotta dalla queryString e verificata con CatalogService) (issue #1894)
  • gwplatform/release_notes.txt
  • Ultima modifica: 2026/10/27 17:46
  • da giorgio.scali