GSIP 127

GSIP 127 - Name Validation / Disable

Overview

Propose the creation of a Naming class to capture the naming restrictions our different protocols operate under.

This utility class can be used to recognize when a name won't work for a specific protocol and a) disable the functionality (for cases like XML encoding) or provide a warning (for cases like style lookup).

Fixing up these warnings is left as a matter for the system administrator.

Proposed By

Jody

Assigned to Release

This proposal is for GeoServer 2.7.x and back ported to 2.6.x as a bug fix.

State

Motivation

This proposal comes out of issues reported again 2.7-beta:

Users have created "styles" that do not match our filename restrictions
WCS coverages commonly start with a number, while WFS where featureTypes which are required to be NCNAME and may not start with a number
The REST API and User Interface do not consistently validate names when creating and editing
Clients written against the previous naming restrictions should continue to function (although perhaps with warnings)

Proposal

Introduction of a Naming utility class:

enum NameValidation {
   STYLE, WORKSPACE, WMS_LAYER, WCS_COVERAGE, WFS_FEATURE_TYPE;
   
   /**
    * Used to generate a default name from a native name.
    */
   Name recommended( String nativeName );

   /**
    * List of warnings, if any, for using the provided name.
    */
   List<String> validate( String name );
}

NameValidation.STYLE.validate( "$foo" ) returns "Invalid name for WMS style".
NameValidation.STYLE.recommended( "foo" ) used when generating an initial style name (from GUI or importer).
NameValidation.WORKSPACE.validate("The Past Through Tomorrow") returns ("Workspace names are limited to 15 characters", "Workspace names may not contain whitespace").
NameValidation.WFS.recommend( "13A" ) generates "_13A" for use when importing a shapefile "13A.shp".
NameValidation.WFS.validate( "13A" ) generates ("Invalid name for use with XML formats"). The recommend method can be used to provide a suggested fix.
NameValidation.WCS.validate( "13A" ) generates an empty list (as the name is valid).

Feedback

Initial feedback indicates that this issue is not isolated to workspace styles.

Jukka has noticed a number of issues around naming limitations in the REST API.

David Winslow disliked the complexity of search the catalog with a range of "fixed names". I have attempted to simplify above.

Andrea strongly disliked the idea of configuration migration and argued in favour of allowing names compatible with only WMS (disabling those layers for WFS).

The initial pull request (https://github.com/geoserver/geoserver/pull/933) has been withdrawn.

A second pull request (https://github.com/geoserver/geoserver/pull/960) just focuses on allowing a wider range of characters.

Clarification based on discussion:

We are trying to solve a regression in the catalog introduced by GeoServer 2.6.
Filenames for styles that used to be valid (example "foo::bar") are no longer
valid due to the file name checking performed by ResourceStore and friends.

Fixing this issue is in three parts:

* Ensure the GeoServer 2.5.x catalog can load (even with warnings)
* Provide a mechanism to fix the file names (either manual or automatic)
* Allow clients that were developed with the invalid names to continue to
  function (while they transition over to the new names)

Backwards Compatibility

This fix will introduce warnings for existing clients that have hard coded invalid style names (example "foo::bar").

When names are migrated proper event notification will need to be sent out so GWC can destroy the prior cache (recorded on disk using a hash of layer, style and rendering parameters).