Thanks for the feedback Andrea. Comments inline.
On Thu, Dec 22, 2016 at 5:20 AM Andrea Aime <andrea.a...@geo-solutions.it>
wrote:
> On Tue, Dec 20, 2016 at 9:21 PM, Justin Deoliveira <jdeol...@gmail.com>
> wrote:
>
> Hi folks,
>
> I'm working on a project with a requirement as follows. Basically I want
> to be able to make a normal OGC (WMS, WFS, etc...) request to GeoServer,
> but I don't want it to fully execute. What I want is it to do pretty much
> all of the request parsing, but then return right before it goes to execute
> that request.
>
> The use case for this project is that the information from the parsed
> request is used to do some on-demand database setup and security that needs
> to happen before the request is executed.
>
> The security in terms of layer access you mean? Restrictions such as
> filters or property reduction won't be applied until actual data access for
> example.
>
The use case is more about general “provisioning” of the database that
needs to happen before hand.
>
>
> However, I can see this perhaps being a useful debugging feature as well.
> Just like other tools have a "dry run" or a "simulate" mode to allow you to
> try out something before actually doing it. Along that vein it could be
> useful to be able to do the same for a GeoServer request, to see how it
> will be processed and parsed, etc... before actually executing it, perhaps
> because it is a request that may take a long time, etc...
>
> Yep, why not.
>
>
> The change I am proposing is as follows. First add a special key value
> pair that will be recognized by the dispatcher (like simulate=true or
> something along those lines).
>
> Will it be recognized also for POST requests?
>
Yup. IIRC the dispatcher supports POST requests with a body but still
allows you to send params via query string as well.
Besides that, thinking out loud here, how about implementing it as a
> DispatcherCallback instead? Or the extra complication in the dispatcher is
> indeed minimal?
>
Yup, my thinking was that I can probably keep all of this code constrained
to a DispatcherCallback… although I was envisioning a bit of refactoring of
some of the utility code. If there are any dispatcher changes my guess is
they will be quite minimal.
>
>
> When the flag is set the dispatcher will do all of the request parsing and
> dispatch it normally does, except for when it gets to the point where it
> would execute the operation it would simply return with a response that
> includes a representation of the request it just parsed.
>
> For the representation of the response I was thinking output similar to
> the output of what the RequestObjectLogger produces, only encoded as
> something structured like JSON and/or XML.
>
>
> Now you are getting me a bit worried... maybe it's nothing, but the
> request objects were not designed to be returned back to the users,
> depending on how deep you go dumping them, you might end up revealing
> information that the admin does not want to be seen, such as for example
> the security filters being applied by something like GeoFence, or the
> datastore connection parameters (ok, that would be quite the deep scan in
> the object tree, but in the end all the info is actually linked and
> reachable from a GetMapRequest object for example).
> In other words, is it something that one would want to always have and
> would come with sane restriction to avoid leaking information, something
> allowed only to admins, something that it's core vs a plugin?
>
>
Good point. What if we made it an explicit “opt-in” enabled only via
configuration or a system property, etc…
Another option could be to simply redact sensitive information when the
user isn’t the admin… Or do you think there are too many cases of sensitive
properties to handle?
Fwiw I wasn’t planning on traversing the object deep enough to get down to
anything like data store connection information. Just
> I was also thinking that for such a request we might try to utilize an
> appropriate http response code. The *202 Accepted* looks like it could
> apply:
>
> *The request has been accepted for processing, but the processing has not
> been completed*
>
>
> Works for me
>
>
> And that's it. Let me know what y'all think. If folks feel this one is
> worth of a GSIP I am happy to whip one up.
>
> I would be happy either way
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054 Massarosa (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39 339 8844549 <+39%20339%20884%204549>
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> -------------------------------------------------------
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
