geoserver / geoserver-cloud

Cloud Native GeoServer is GeoServer ready to use in the cloud through dockerized microservices.

Home Page:http://geoserver.org/geoserver-cloud

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

regression: does not load stored password from xml in datadir

danduk82 opened this issue · comments

Problem:

When loading a layer configured in datadir with a normal postgis store, the connection informations are not loaded properly. (Is this a regression since we introduced JNDI support maybe?)

Step to reproduce:

  • using datadir profile
  • create a postgis store
  • set connection parameters (so that they are saved in datadir xml files)
  • create a layer
  • test: the layer works
  • kill the wms container (for example, this actually happens with all)
  • test the layer again, it fails and the error messages says that the password is wrong.

If you re-save the store (i.e. that the config event via rabbitMq is sent, then the layer works again...)

see

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE ServiceExceptionReport SYSTEM "http://gscloud.local/geoserver-cloud/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd"> <ServiceExceptionReport version="1.1.1" >   <ServiceException>
      java.lang.reflect.UndeclaredThrowableExceptionUnable to obtain connection: Cannot create PoolableConnectionFactory (FATAL: password authentication failed for user &quot;username&quot;)
Cannot create PoolableConnectionFactory (FATAL: password authentication failed for user &quot;username&quot;)
FATAL: password authentication failed for user &quot;username&quot;
</ServiceException></ServiceExceptionReport>

The problem was related to the optimized catalog loader, a dependency upstream.
GeoServer saves the passwords encrypted. When loading the catalog, they're uncrypted.
Since the optimized catalog loader parses CatalogInfo objects in parallel, the pwd decryption needs to happen once all stores are parsed, on the main thread, to avoid a nasty spring deadlock.
This was indeed happening, but the DataStoreInfos are ModificationProxy's, and hence when the unencrypted password was set back to the DataStoreInfo connection parameters, the change was lost in the ModificationProxy change list, never committed to the actual DataStoreInfo object.

Thanks :)