Differenze
Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.
| 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) | ||