Browser based Spatial Data Infrastructure typically combines data from a variety of domains on a single web application (for example GeoNetwork). There are two typical errors that block optimal user experience in browser-SDI, which need some special attention. In both cases these errors appeared since browsers enforce stricter rules to prevent abuse. Similar to the introduction of popup-blockers. Fortunately there are common solutions to these issues, but it needs some attention when setting up the environment.

Mixed content

Mixed content errors are caused by the limitation of browsers to embed http (non secure) resources (images, scripts, ajax) in https (secure) websites. Typical behaviour of this limitation is that in a metadata catalogue that runs on https, any http thumbnail or wms-layer will not display.

For sure the best approach is to run all (governmental) websites on https, which for example for the Netherlands will be legally required in 2018. However currently we’re far from that point.

For the intermediate period I recommend to run the public part of the catalogue on http (non secure). However it is a good practice, when users login, to use a secure protocol. Recently a new browser limitation has even been introduced which prevents any user to login on any non secure website. Therefore we offer over http and https, as soon as users try to login we redirect them to the https variant.

For content providers experiencing usability problems when adding non secure content, we display warnings when we identify mixed content. Else we suggest them to switch off the mixed content limitation, which is currently optional in browsers.

I want to mention one more aspect related to the use of https in GeoNetwork. In some situations the java application tries to load an external https resource and fails, but the browser may load that file without problems. The problem may be that java allows only a subset of certificates that browsers allow. The dutch government root certificate is for example not trusted by default by java.You can easily resolve this problem by adding the missing certificates to the java certificate store.

Cross domain scripting

Cross domain scripting errors (induced by same origin policy) occur when webpages request resources from other websites by using ajax. In browser-SDI ajax is typically used to retrieve a getcapabilities, wms:getfeatureinfo, csw:getrecords or wfs:getfeatures response from an external server. Traditionally GeoNetwork worked around this cross domain issue by introducing a proxy that routes the request via the GeoNetwork server to the external server. There are however some limitations and security issues with this approach.

  • The approach is slower then direct connection to the external server (and gives unnecessary load on the GeoNetwork server)
  • By default this proxy is configured to allow traffic to any external server, which opens options to abuse the proxy to surf the web anonymously. When installing GeoNetwork I recommend to configure the proxy to allow access to only those domains relevant to the catalogue.
  • When accessing secured services the proxy will not be able to forward the OAuth/SAML tokens that identify the user.

The answer to cross domain errors is CORS. CORS is a setting on the domain that is providing the services (geoserver/mapserver). Each data provider offering services to be shared on multiple environments should have the CORS setting activated, especially those providing secured services. The CORS setting is typically managed on the Apache or Tomcat level.