[Geoserver-devel] Proposing new community module: Parameters from path extraction (REST like URLs)

GeoServer GeoServer Developer
1

Hi,

This community module will allow entering specific request parameters as URL path fragments (REST like URLs) instead of using the query string.

For example, we want to be able to apply a cql_filter using a URL in the following form:

http://:/geoserver//**//**ows?service=WMS&version=1.3.0&request=GetMap

As a simple example of usage, if the is something like:

cql_filter=seq=‘K140M’

the URL would become:

http://:/geoserver///K140M**/**ows?service=WMS&version=1.3.0&request=GetMap

and the proposed community module will translate the URL to this new one:

http://:/geoserver///ows?service=WMS&version=1.3.0&request=GetMap&cql_filter=seq=‘K140M’

This community module could be used to enable REST like URLs for clients that are not able to consume OGC protocols directly.

This module is configured by a set of rules that will allow us to select the URLs that should be transformed and describe the transformation to be applied:

The match attribute contains a Java Regular Expression that is used for two proposes:

  • selecting the URLs that should be transformed

  • extract the pieces of information (groups) than can be used to describe the transformation.

The parameter attribute defines the parameter that should be added to the query, in this case the ‘cql_filter’ parameter.

The remove attribute must reference a valid group of the match expression (typically the must external one) which will be removed from the original URL.

The transform attribute defines the parameter value content. The transform string can reference any valid group of the match expression.

This module can be implemented as Servlet Filter which will give us total control over when it should be executed (regarding the filters chain), but this will make it harder to implement a “plug and play” behavior.

Another option is to implement this module as a filter that extends the GeoServerFilter and ExtensionPriority interfaces, this will make very easy to implement the “plug and play” behavior but the filter will be executed by the
SpringDelegatingFilter filter which is executed only after the AdvancedDispatchFilter filter and I’m not sure to understand all the implications of this.

Any feedback on this is welcome.

Best regards,

Nuno Oliveira

2

+1 That sounds really cool, and very tricky to document!

Can you do what you need with a community module or will some changes to core be required?

On Sun, Jan 24, 2016 at 6:15 AM Nuno Miguel Carvalho Oliveira <nmco51845@anonymised.com> wrote:

Hi,

This community module will allow entering specific request parameters as URL path fragments (REST like URLs) instead of using the query string.

For example, we want to be able to apply a cql_filter using a URL in the following form:

http://:/geoserver//**//**ows?service=WMS&version=1.3.0&request=GetMap

As a simple example of usage, if the is something like:

cql_filter=seq=‘K140M’

the URL would become:

http://:/geoserver///K140M**/**ows?service=WMS&version=1.3.0&request=GetMap

and the proposed community module will translate the URL to this new one:

http://:/geoserver///ows?service=WMS&version=1.3.0&request=GetMap&cql_filter=seq=‘K140M’

This community module could be used to enable REST like URLs for clients that are not able to consume OGC protocols directly.

This module is configured by a set of rules that will allow us to select the URLs that should be transformed and describe the transformation to be applied:

The match attribute contains a Java Regular Expression that is used for two proposes:

  • selecting the URLs that should be transformed

  • extract the pieces of information (groups) than can be used to describe the transformation.

The parameter attribute defines the parameter that should be added to the query, in this case the ‘cql_filter’ parameter.

The remove attribute must reference a valid group of the match expression (typically the must external one) which will be removed from the original URL.

The transform attribute defines the parameter value content. The transform string can reference any valid group of the match expression.

This module can be implemented as Servlet Filter which will give us total control over when it should be executed (regarding the filters chain), but this will make it harder to implement a “plug and play” behavior.

Another option is to implement this module as a filter that extends the GeoServerFilter and ExtensionPriority interfaces, this will make very easy to implement the “plug and play” behavior but the filter will be executed by the
SpringDelegatingFilter filter which is executed only after the AdvancedDispatchFilter filter and I’m not sure to understand all the implications of this.

Any feedback on this is welcome.

Best regards,

Nuno Oliveira

Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

–
Jody Garnett

3

Hi Jody,

Sorry for the delay in the reply.

Regarding the documentation, yes this is not easy to document … I will have to use a lot of examples.
By the way, this module includes an UI which helps design and manage the rules (it is also possible to test the rules in the UI).

No changes in the core will be required.
I have used the GeoServerFilter and ExtensionPriority extension points, basically I wrap the HttpServeletRequest with a custom wrapper that will provide the transformed request info.

The work is pretty much done … tomorrow I will do a pull request for this.

Regards,


<details class='elided'>
<summary title='Show trimmed content'>&#183;&#183;&#183;</summary>

2016-01-24 19:49 GMT+00:00 Jody Garnett <[jody.garnett@anonymised.com](mailto:jody.garnett@anonymised.com..403...)>:

> +1 That sounds really cool, and very tricky to document!
> 
> Can you do what you need with a community module or will some changes to core be required?
> 
> On Sun, Jan 24, 2016 at 6:15 AM Nuno Miguel Carvalho Oliveira <[nmco51845@anonymised.com](mailto:nmco51845@anonymised.com)> wrote:
> 
> > Hi,
> > 
> > This community module will allow entering specific request parameters as URL path fragments (**REST like URLs**) instead of using the query string.
> > 
> > For example, we want to be able to apply a cql_filter using a URL in the following form:
> > 
> > http://<host>:<port>/geoserver/<workspace>/<layer>**/<filter>/**ows?service=WMS&version=1.3.0&request=GetMap
> > 
> > As a simple example of usage, if the <filter> is something like:
> > 
> > cql_filter=seq='**K140M**'
> > 
> > the URL would become:
> > 
> > http://<host>:<port>/geoserver/<workspace>/<layer>/**K140M****/**ows?service=WMS&version=1.3.0&request=GetMap
> > 
> > and the proposed community module will translate the URL to this new one:
> > 
> > http://<host>:<port>/geoserver/<workspace>/<layer>/ows?service=WMS&version=1.3.0&request=GetMap&**cql_filter=seq='K140M'**
> > 
> > This community module could be used to enable **REST like URLs** for clients that are not able to consume OGC protocols directly.
> > 
> > This module is configured by a set of rules that will allow us to select the URLs that should be transformed and describe the transformation to be applied:
> > 
> > <Rules>
> > <Rule **match**="^.*?(/(a-zA-Z0-9_\-]+))/[^/]+$"
> > **parameter**="cql_filter"
> > **remove**="$1"
> > **transform**="seq='$2'"/>
> > <Rule .../>
> > </Rules>
> > 
> > The **match** attribute contains a [Java Regular Expression](https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html) that is used for two proposes:
> > 
> > - selecting the URLs that should be transformed
> > 
> > - extract the pieces of information (**groups**) than can be used to describe the transformation.
> > 
> > The **parameter** attribute defines the parameter that should be added to the query, in this case the 'cql_filter' parameter.
> > 
> > The **remove** attribute must reference a valid group of the **match** expression (typically the must external one) which will be removed from the original URL.
> > 
> > The **transform** attribute defines the parameter value content. The **transform** string can reference any valid group of the **match** expression.
> > 
> > This module can be implemented as Servlet Filter which will give us total control over when it should be executed (regarding the filters chain), but this will make it harder to implement a "plug and play" behavior.
> > 
> > Another option is to implement this module as a filter that extends the **GeoServerFilter** and **ExtensionPriority** interfaces, this will make very easy to implement the "plug and play" behavior but the filter will be executed by the
> > **SpringDelegatingFilter** filter which is executed only after the **AdvancedDispatchFilter** filter and I'm not sure to understand all the implications of this.
> > 
> > Any feedback on this is welcome.
> > 
> > Best regards,
> > 
> > Nuno Oliveira
> > 
> > ------------------------------------------------------------------------------
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > [http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140](http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140)_______________________________________________
> > Geoserver-devel mailing list
> > [Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
> > [https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)
> 
> --
> 
> --
> Jody Garnett

</details>