Re: [Geotools-devel] GSIP 218: Control remote HTTP requests sent by GeoTools \ GeoServer

2023-03-28 Thread Jody Garnett
There was a good discussion in today's meeting and I have an action item to take my feedback to the email list. But first of all +1 this is an excellent addition to the codebase, and a good way to gradually introduce more safety measures to the project with small attainable goals. And now for the

Re: [Geotools-devel] GSIP 218: Control remote HTTP requests sent by GeoTools \ GeoServer

2023-03-28 Thread Simone Giannecchini
+0, I think it is pretty much needed for security. Regards, Simone Giannecchini == Online training classes for GeoNode, GeoServer and MapStore from the experts! Visit https://www.geosolutionsgroup.com/professional-training/ for more information. == Ing. Simone Giannecchini @simogeo Founder/Directo

Re: [Geotools-devel] GSIP 218: Control remote HTTP requests sent by GeoTools \ GeoServer

2023-03-23 Thread Andrea Aime
Hi Jody, the proposal indicates the scope of the initial implementation: WMS remote SLD, WMS feature portrayal, WPS remote inputs. That said, yes, entity resolution as set up in AllowListEntityResolver could be rewritten to operate against a URLChecker... I guess the GeoServer URL checker could bi

Re: [Geotools-devel] GSIP 218: Control remote HTTP requests sent by GeoTools \ GeoServer

2023-03-22 Thread Jody Garnett
Idea (feel free to indicate if it is out of scope). Environmental variables were introduced to control access for entity resolution: - It may be possible to replace these with the new URLChecker and simplify the application. Or; - show them as a URLChecker that cannot be disabled in the user inter

Re: [Geotools-devel] GSIP 218: Control remote HTTP requests sent by GeoTools \ GeoServer

2023-03-22 Thread Andrea Aime
Yep, makes sense, proposal updated. Cheers Andrea On Wed, Mar 22, 2023 at 6:31 PM Jody Garnett wrote: > Indeed if you are just intended to back from a regex; then rephrase the > javadoc or make the method name more clear than "evaluate": > > /** > * Provide implementation to evaluate l

Re: [Geotools-devel] GSIP 218: Control remote HTTP requests sent by GeoTools \ GeoServer

2023-03-22 Thread Jody Garnett
Indeed if you are just intended to back from a regex; then rephrase the javadoc or make the method name more clear than "evaluate": /** * Provide implementation to evaluate location/URL/URI passed in string form * * @param location the subject of evaluation * @return true i

Re: [Geotools-devel] GSIP 218: Control remote HTTP requests sent by GeoTools \ GeoServer

2023-03-22 Thread Andrea Aime
Hi Jody, while the suggestion seems to clarify things, it seems to me it's making the implementation harder. With a regular expression based system, how do you distinguish BLOCK and NO_OPINION (imagine we'd have different implementations, one based on regexes for user configured sites, and another

Re: [Geotools-devel] GSIP 218: Control remote HTTP requests sent by GeoTools \ GeoServer

2023-03-22 Thread Jody Garnett
The URL checker has a yes/no response - but is written as a yes/don’t care - since to access only one URL checker needs to say yes. To address feedback: - Adjust javadoc, or - Provide three states: ALLOW, BLOCK, NO_OPINION My preference is to return an Enum even if just two states are permitted t

[Geotools-devel] GSIP 218: Control remote HTTP requests sent by GeoTools \ GeoServer

2023-03-22 Thread Andrea Aime
HI all, this is a revival of the old GSIP-189, a bit modernized, with a smaller initial scope (that should help us get an implementation going safeguarding some remote access functionality sooner rather than later). Please review, discuss, vote: https://github.com/geoserver/geoserver/wiki/GSIP-218