The tests should pass in eclipse (although I can’t be certain), I moved everything that is viable to move upstream to geotools. Based on the failure, it looks like owsAll.xsd is still in geoserver; maybe try removing the ows module from you eclipse setup then adding it to your build bath as a standalone jar?
The tests should certainly pass in maven, I made sure that all the file resolution stuff would work there.
Kevin,
are you seeing these failures in Maven or Eclipse?
If the latter, please refer to the off-list vulnerability discussion “GeoServer XXE bypass ticket”. I have included a couple of these below for your convenience.
Is something (like an Eclipse build) copying these resources into a target directory where it is then captured by Eclipse transitive dependency inclusion? Have you built with clean and eclipse:clean and a full workspace clean and rebuild and then an Eclipse restart (and stand up and run around your desk three times)?
Torben, do you expect unit tests to pass in Eclipse?
Kind regards,
Ben.
-------- Forwarded Message --------
Subject: Re: GeoServer XXE bypass ticket
Date: Fri, 03 Jul 2015 07:37:00 +1200
From: Ben Caradoc-Davies <ben@anonymised.com>
[…]
CC: […] Kevin Smith <ksmith@anonymised.com> […]
[…]
classpath dependencies are resolved as file: URLs if they are resources
of the current module or project dependencies in Eclipse (i.e. other
GeoServer modules), and as jar: URLs if they are GeoTools module
dependencies in Maven or GeoTools dependencies.
The standard Eclipse setup (GeoServer modules are project dependencies,
GeoTools dependencies are jar files referenced from your Maven repo)
will give different URL types; Maven always resolves dependencies as
jars from the Maven repo, even between GeoServer modules.
You may get more failures in Eclipse! A sneaky solution would be to move
xsd dependencies into GeoTools and then forbid file: URLs.
Kind regards,
Ben.
-------- Forwarded Message --------
Subject: Re: GeoServer XXE bypass ticket
Date: Fri, 03 Jul 2015 09:19:06 +1200
From: Ben Caradoc-Davies <ben@anonymised.com>
[…]
CC: […] Kevin Smith <ksmith@anonymised.com> […]
[…]
there is already a copy of wcsAll.xsd in the GeoTools net.opengis.wcs
module:
modules/ogc/net.opengis.wcs/schemas/wcs/1.1.1/wcsAll.xsd
It looks like it was only used for generating the bindings (with
xmlcodegen), and does not appear to be included in the jar for this
module. Including it may introduce more problems as this schema has
cross-source imports, e.g from wcsGeoCoverage.xsd (note …/…/):
<import namespace=“http://www.opengis.net/ows/1.1”
schemaLocation=“…/…/ows/1.1.0/owsAll.xsd”/>
gt-xml SchemaResolver was written to overcome these problems and to
allow resolution of test dependencies across jar files. It is not just
for downloading schemas.
Kind regards,
Ben.
On 31/07/15 08:40, Kevin Smith wrote:
I’m getting unit test failures in several tests of
org.geoserver.wfs.v1_1.GetFeatureTest due to the following exception
which seems to relate to the GEOS-7032 fix
org.xml.sax.SAXException: Entity resolution disallowed for
file:/home/smithkm/og-proj/geoserver/src/ows/target/classes/org/geoserver/ows/xml/v1_0/owsAll.xsd
Entity resolution disallowed for
file:/home/smithkm/og-proj/geoserver/src/ows/target/classes/org/geoserver/ows/xml/v1_0/owsAll.xsd
The failures seem to be stateful, depending on the other unit tests
being run, which commit I’m on, etc. It’s not as simple (for a rather
complicated definition of simple) as one previous test leaving some
state in place that breaks the test. There’s some more complicated
interaction of different factors going on that I haven’t figured out.
The only thing that’s consistent is that the tests will pass when run as
part of the full set of GeoServer unit tests, and will pass when run in
isolation, regardless of which of my machines, which commit I build
from, which JDK I use (Oracle 7, Oracle 8, OpenJDK 7).
in
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.resolveDocument(XSDDescription,
Map, XMLEntityResolver)
it’s trying to look up
…/…/ows/1.0.0/owsAll.xsd
from
jar:file:/home/smithkm/.m2-normal/repository/org/geotools/xsd/gt-xsd-wfs/14-SNAPSHOT/gt-xsd-wfs-14-SNAPSHOT.jar!/org/geotools/wfs/v1_1/wfs.xsd
and then “expanding” that to get
file:/home/smithkm/og-proj/geoserver/src/ows/target/classes/org/geoserver/ows/xml/v1_0/owsAll.xsd
This then runs afoul of the restriction on looking up XSDs from the
local file system.
In the non failing case, there’s no attampt to resolve owsAll.xsd in
XMLSchemaLoader.resolveDocument at all.
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
