In a perfect world the ServiceException would only return information when
the client has made the mistake incorrectly, in this case the
ServiceException looks to be due to a configuration problem with your data
store?
That is a tricky one, you can cut down on the information returned during
server configuration
There are a couple global settings about service exception here:about).
-
http://docs.geoserver.org/stable/en/user/webadmin/server/globalsettings.html
Try that, if your admin is still not satisfied you will need to do a code
audit of the "JDBC DataStore" code and submit a patch masking any SQL
Exception information that is passed back:
- https://github.com/geotools/geotools/tree/master/modules/library/jdbc
-
https://github.com/geotools/geotools/tree/master/modules/plugin/jdbc/jdbc-oracle
If have you a team in place to do the work we would love the participation,
if not check out the commercial support page.
a) The formal approach would be to introduce strict error codes (also used
for translation) and provide a "minimal" translation of the error codes for
use in production.
b) The quick band-aid would be to patch where GeoServer produces a
ServiceException document and force it to provide no details of the
mistake.
Normally a web service service would return an *HTTP *500 Internal Server
Error or something. An OGC WebService can actually return a *HTTP 200 OK*
response that contains a ServiceException document.
Jody Garnett
On Thu, Jun 5, 2014 at 5:58 AM, Aijun Chen <[email protected]> wrote:
> Hi,
>
> We are using GeoServer WFS to serve Vector Data that are stored in Oracle
> Database in backend.
>
> The WFS request directly returned errors that produced by Oracl DB to
> final users.
> For example, when we submitted below WFS request to any GeoServer instance:
>
> http://geoserver.domain.name/GeoServer/wfs?service=WFS&version=1.0.0&request=GetFeature&outputFormat=json&srsName=EPSG:4326&typeName=YOUR_LAYERNAME&cql_filter=1='string
> '
> The GeoServer returned below errors to final users if backend database is
> Oracle (I did not have a chance to test PostGIS as backend database):
> java.lang.RuntimeException: java.io.IOException java.io.IOException null
> ORA-01722: invalid number
>
> This error directly discloses backend database information to final users.
> Our security guys think that this is a secure vulnerability and we need
> fix it.
>
> Considering that this error is directly returned by GeoServer.
> I am seeking any comments/suggestion/advises from users and developers
> from GeoServer community to see if there is any way that we can fix this
> issue.
>
> Any responses are highly appreciated!
>
> Anderson Chen,
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Geoserver-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
