We use MapServer as a lightweight GIS engine in many of our products, giving us WMS/WFS API endpoints for a wide range of purposes. When upgrading the Colchester Heritage Explorer website, an ASP.NET Core MVC site made with cloudscribe and HBSMR WEB/API components, I dived in to configure and test the MapServer instance. I followed our usual processes, enabled the CGI extension to execute, setting folder permissions to allow MapServer to write out log files, configured our secure MapServer Proxy component, etc.

But it wasn’t working.

One of our first tests of a MapServer instance is to browse to the location of the main MapServer executable, in this case the address was:

https://colchesterheritage.co.uk/wwwroot/MapServer/Scripts/mapserv.exe

but instead of a nice diagnostic response, I got “401 – Unauthorized: Access is denied due to invalid credentials”:

This was very puzzling, as I already had this working perfectly in a parallel test site, on the same server with identical configuration in every respect – or so I thought. Both sites were using an application pool with Identity set to ApplicationPoolIdentity, folder permissions were all good for this identity, there were no ip restrictions, and no reason I could see for it not to work.

Except that I’d forgotten about the Anonymous Authentication Credentials… in IIS select the site > Authentication > select Anonymous Authentication and click “Edit…” > I found the default setting:

And of course I had not set up permissions for this user to access the location of the MapServer files. So there are two solutions: a) less preferred: add the IUSR account at the root of site with default permissions:

(if I were using this solution I would also tick “Deny” for the “Write” setting off bottom of that image);

or b) preferred: change the Anonymous Authentication Credentials for the site to the Application pool identity:

After making this change, on browsing to our MapServer executable I saw the expected response “Noquery information to decode. QUERY_STRING is set, but empty. ” which means the CGI application is working.

Phew – problem solved!

My next step in hardening this site is to block this direct access, and route all requests through a secured proxy, so the above URL to the exe won’t work by the time you read this if we’ve done our security right.

To see the working result, check out the maps within the Colchester Heritage Explorer, for example this map of the historic buildings and sites that are included on the Colchester “Local List”.

And here’s a rather nice map of WW2 pillboxes and related defensive sites around Colchester, generated by a MapServer WFS request in response to a a free text search on “pillboxes”:

I hope this helps someone, and please feel free to add comments below.

All went well and we modified the mapserver geojson output format to specify the field we wanted to use (originally named id in our case) but adding in the line: FORMATOPTION "LCO:ID_FIELD=id"

OUTPUTFORMAT
   NAME "geojson"
   DRIVER "OGR/GEOJSON"
   MIMETYPE "application/json; subtype=geojson"
   FORMATOPTION "STORAGE=stream"
   FORMATOPTION "FORM=SIMPLE"
   FORMATOPTION "LCO:COORDINATE_PRECISION=0"
   FORMATOPTION "LCO:ID_FIELD=id"
END

The field “id” needed to be included in the relevant map layer in the gml_include_items e.g.:

"gml_include_items"     "name,recsubtype,recsubtypecode,rectype,ref,uid,id"

After those changes – all seemed to be going well and the id was appearing in our WFS return

However when we looked at some of the other attributes we noticed scrambled characters (these had been fine with the previous version of mapserver). e.g. rectype in screenshot below

Our data was coming from SQL server using the msplugin_mssql2008 plugin– and if we set debug in the mapserver layer and looked at the log we saw:

msConvertWideStringToUTF8(): General error message. Unable to convert string in encoding 'UCS-2LE' to UTF8 An invalid multibyte sequence has been encountered in the input

So it looked as it something was going wrong in the unicode translation.  The workaround was refreshingly simple – we just had to alter the view that the data was being pulled from to force the conversion e.g. change:

‘Site’

to:

CONVERT(nvarchar(1),N’Site’)

then all was well again.

The problem...

If you publish a SQL Server (in this case 2014) table or view with a GUID field using GeoServer (version 2.10), it will fail to make  a valid WFS because the &request=DescribeFeatureType response will not include these layers.

This manifests itself in various ways depending on the client, but in QGIS on trying to load the layer into the map we get this in the "Log Messages Panel":

Analysis of DescribeFeatureType response failed for url  srsname='EPSG:27700' typename=xxx:yyyurl='https://mysite.com/myworkspace/wfs' version='1.0.0' table="" sql=: it is probably a schema for Complex Features

which had me puzzled for quite some time!

The solution...

Changing the data source view to include this field with

CAST(myGUID AS varchar(36)) AS myGUID

then hitting "Reload feature type" in the GeoServer layer configuration screen fixes it. This changes the field data type from "UUID" to "string" in that screen. Or just omit the field entirely.

My guess is this will not help transactional WFS, but I have not tested this. Overall, GUIDs are still best avoided in GIS-land as they are so poorly supported by the database drivers.