Having a NAMESPACE url parameter in a WFS request causes a HTTP 403 error

GeoServer GeoServer User
1

Hi all,

We noticed that having a NAMESPACE parameter in a WFS request causes an HTTP 403 error. This happens on a GeoServer instance where I don’t have direct access, so I don’t exactly know how it is configured. I can give some recommendations to the administrator, though. This problem occurred when they upgraded their GeoServer instance to version 2.25 from a previous maintenance version.

The following request fails with “403 Forbidden” error:

GET https://www.company.com/geoserver/customer_c/wfs
  ?service=WFS
  &version=1.1.0
  &request=DescribeFeatureType
  &typeName=customer_c:Data
  &NAMESPACE=xmlns(customer_c=https://company.com/geoserver/customer_c)

If I omit the NAMESPACE parameter or remove the customer_c= prefix from the parameter, the request succeeds. Both requests have the same Authorization header.

Could this be a configuration issue with workspace permissions or could it be a GeoServer bug?

Thanks in advance,
Lauri

2

Hi,

I do not know if this is a meaningful test, but with Geoserver 2.25.3 and the default data directory this works fine:

http://localhost:8080/geoserver/topp/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=topp:states&NAMESPACE=xmlns(topp=http://localhost:8080/geoserver/topp)

-Jukka-

3

Hi,

Why would you pass that namespace parameter if it works without? Are you using the same uri as in the Geoserver catalog? It isn’t necessary the url of the web site. You would see that from the resulting xml without that parameter.

Best regards,
Roar Brænden

4

That may be working as expected, see Configuration Considerations — GeoServer 2.27.x User Manual

Namespace should be restricted to safe locations, is that location the same as your proxy base url location?

The other possibility is that you have security on that location, and the XML parser trying to access to DescribeFeatureType is failing.

5

Does using &NAMESPACE= trigger any entity resolving really? Why does this request work fine as well?

http://localhost:8080/geoserver/topp/wfs?service=WFS&version=1.1.0&request=DescribeFeatureType&typeName=topp:states&NAMESPACE=xmlns(topp=https://foo.com/bar)

The name “customer_c” should be OK, but I would still test if the issue is the same with “customerc”. I would also check if the company has something in front of Geoserver and if the 403 Forbidden error comes before the request is reaching Geoserver.

6

I’m using FME 2022 to connect to the WFS api and for some reason it adds the NAMESPACE parameter to the request and I can’t affect to that. There’s a new option in FME 2024 to omit the namespace parameter, but currently I’m stuck to 2022.

Yes, it is the same.

That is indeed a question to be asked. Actually the 403 HTTP response in this case is different kind than the normal 403 responses by GeoServer. I’ll look more into this.

7

Thank you for your ideas!

I believe the proxy base URL is misconfigured to use http:// instead of https://, which is used in the namespace. We’ll try changing that to see if it helps.

You mentioned that this might have something to do with External Entities Resolution security. I don’t understand what (external) entity is requested here and possibly blocked. The documentation states: “This is most commonly seen when the XML request provides the location of an XSD schema for validation.”. Does the namespace parameter have something to do with the schema location?

I still don’t quite understand what the namespace parameter is actually doing. In my test environment, it doesn’t affect the DescribeFeatureType responses in any way. I have tested with both a default workspace and a restricted isolated workspace.