WFS DescribeLayer isn't working with authenticated user and restricted access

Unfortunately, I cannot reproduce this issue with the demo data. I did the following

Added a "testuser" with an associated role "testrole".
Added a rule sf:roads.r for the testrole
Added a rule sf:streams.r for the ADMIN role

I developed a tiny test client using basic auth and issuing DescribeFeatureType requests.
For sf:roads, I get the proper answers.
For sf:streams, I get an error message indicating that this layer does not exist. (I think this is correct for catalog mode HIDE).

I never got a NPE !!!

Can you please reconstruct the NPE using the sf workspace, zip the GEOSERVER_DATA_DIR/security directory and attach the zip file. The exact test URLs would be nice.

Thanks

I can reproduce it but I am uncertain how to fix it. For reproducing, I did

1) add a role "testrole"
2) add a user testuser with role "testrole"
3) The data security page has 4 rules

..r ADMIN
. w ADMIN
sf.roads.r testrole
sf.roads.w testrole

The catalog mode is HIDE.

4) Go to Demo requests, select "WFS_describeFeatureType-1.1.xml", replace topp:states with sf:roads, enter credentials for testuser and click submit.

The NPE happens in FeatureTypeSchemaBuilder line 185 (master branch)

String targetNamespace = catalog.getNamespaceByPrefix(targetPrefix).getURI();

because getNameSpaceByPrefix(targetPrefix) returns null since the catalog mode is HIDE. I think returning null here is not correct.

Doing the request with sf:streams creates a response telling that there is no such layer. I think this is correct.

Switching to catalog mode MIXED produces for sf:roads and sf:streams
<servlet-exception>
HTTP response: 404
Not Found
</servlet-exception>

I think this is not correct for sf:roads

Switching to catalog mode CHALLENGE

Produces a valid schema for sf:streams and sf:roads, I think this is not correct for sf:streams.

Maybe I am wrong with some assumptions, for the moment I am confused and have no idea how to fix it. I have seen that Justin and Ben developed this class, please can one of you reassign this issue to himself.

Looked into this and this was actually an issue in 2.1 as well (same error) so not related to the new security stuff or virtual services. The issue is that the DFT endpoint has to do a namespace lookup to get the uri from the FeatureType that is describing. But as the rule tree dictates the user has no access to the workspace, only a single layer within it.

Not sure how to proceed myself. A workaround which handles this specific case is to have the DFT code prevent the workspace URI lookup by getting the uri directly from the feature type. Which is probably a good thing to do anyways to avoid an unnecessary catalog lookup.

Another solution might be to grant read to the workspace if you have read access to any of the layers inside of it... although this would probably have deeper repercussions.

Is it possible to allow read-type access without allowing read-data access, or allow anyone with read-data access to read all type information in a workspace?

Does the type contain confidential information? Even the default CRS can be a large hint about data content.

Thanks so far for looking in to it. I'm not sure if I can help here. But if it helps I can test anything you want. Just let me know.

Will that bug be fixed in the 2.2 release?
Or can I make any workaround to avoid the null pointer and getting the restricted access to work (by data, not by service)?

@Daniel: Unfortunately this case is a bit more complicated than originally thought so no, it won't be making it into 2.2.0. But luckily it is being made priority for 2.2.1 which will be released within one months time.

@Daniel: For the time being i have attached a patched wfs jar which will solve part of the problem, and I think your specific case. Try it out and let me know how it works. The plan is to fix this as soon as 2.2 goes out.

Thx Justin!! Works perfect with the RC2.
We will stay at this version and waiting for the 2.2.1 release!

COol, thanks for confirming Daniel. The jar will also work with 2.2.0 if you want to use that for the time being.

2.2.1 is out, you know?

Justin, is the patch anywhere to be found? Someone could add a test and commit it.

Git to the rescue! The patch was sitting around in my stash queue