v1.9.0

Known issues

• There is a shift in GeoServer WMS/WFS for EPSG 5514 #228
  • Workaround if you have already installed v1.9.0: replace a definition of 5514 in layman/deps/geoserver/data/user.projections/epsg.properties file with

    5514=PROJCS["S-JTSK / Krovak East North",GEOGCS["S-JTSK",DATUM["System Jednotne Trigonometricke Site Katastralni",SPHEROID["Bessel 1841",6377397.155,299.1528128,AUTHORITY["EPSG","7004"]],TOWGS84[572.213,85.334,461.94,4.9732,-1.529,-5.2484,3.5378],AUTHORITY["EPSG","6156"]],PRIMEM["Greenwich",0.0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.017453292519943295],AXIS["Geodetic longitude",EAST],AXIS["Geodetic latitude", NORTH],AUTHORITY["EPSG","4156"]],PROJECTION["Krovak",AUTHORITY["EPSG","9819"]],PARAMETER["latitude_of_center",49.5],PARAMETER["longitude_of_center",24.833333333333332],PARAMETER["azimuth", 30.288139722222223],PARAMETER["pseudo_standard_parallel_1",78.5],PARAMETER["scale_factor",0.9999],PARAMETER["false_easting",0.0],PARAMETER["false_northing",0.0],UNIT["m", 1.0],AXIS["X",EAST],AXIS["Y",NORTH],AUTHORITY["EPSG","5514"]]
    

    and restart GeoServer.
  • Fixed in v1.9.1.

Upgrade requirements

• Set environment variable LAYMAN_OUTPUT_SRS_LIST that contains list of EPSG codes that will appear as output spatial reference systems in both WMS and WFS. Choose any EPSG codes you need and add two mandatory systems 4326 and 3857.

  • Sample SRS list for World: 4326,3857
  • Sample SRS list for Czech Republic: 4326,3857,5514,102067,32633,32634
  • Sample SRS list for Latvia: 4326,3857,3059

  During startup, Layman passes definitions of each EPSG to GeoServer, either from its internal sources, or from epsg.io. If download from epsg.io fails, warning Not able to download EPSG definition from epsg.io appears in log. In such case, you can set EPSG definition manually and restart GeoServer.

  If you want to be sure that GeoServer understands each of your SRS that you passed into LAYMAN_OUTPUT_SRS_LIST, visit GeoServer's admin GUI, page Services > WMS or WFS, and click on Submit. If you see no error message, everything is OK.

  It can be also useful to generate output bounding box for every supported SRS in WMS Capabilities documents. You can control this in GeoServer's admin GUI, page Services > WMS, checkbox "Output bounding box for every supported CRS".

Migrations

Data manipulations that automatically run at first start of Layman:

• Data version table is created.
• GeoServer's security rules of each publication are recalculated according to publication's access rights. It fixes #200 also for existing layers.
• Mistakenly created users and roles in GeoServer, created for public workspaces, are deleted.

Changes

• One of OAuth2 HTTP headers, AuthorizationIssUrl, is optional if and only if there is only one OAuth2 authorization server registered at Layman. The header was mandatory in 1.8.0 and sooner.
• Information about data version including migration ID is stored in PostgreSQL.
• When public workspace is created, only workspace is created on GeoServer. Previously also user and roles were mistakenly created.

v1.8.1

Upgrade notes

• The fix of #200 affects only newly posted or patched layers. To fix access rights on existing layers, you can either wait for 1.9 release (2021-01-15), or manually add ROLE_AUTHENTICATED for every layer security rule which already contains ROLE_ANONYMOUS.

Changes

• #200 Access rights EVERYONE is correctly propagated to GeoServer also for authenticated users. Only newly posted or patched layers are affected by the fix.
• One of OAuth2 HTTP headers, AuthorizationIssUrl, is optional if and only if there is only one OAuth2 authorization server registered at Layman. The header was mandatory before 1.8.1 in any case.

v1.8.0

Upgrade requirements

• Set environment variable LAYMAN_AUTHN_HTTP_HEADER_NAME that serves as a secret. Only combination of lowercase characters and numbers must be used for the value.
• Set environment variable LAYMAN_PRIME_SCHEMA. It is the name of the DB schema, so it is subject to the restrictions given by PostgreSQL. We recommend value _prime_schema if possible.
• Replace LAYMAN_AUTHZ_MODULE environment variable with GRANT_CREATE_PUBLIC_WORKSPACE and GRANT_PUBLISH_IN_PUBLIC_WORKSPACE. The following settings correspond best with behaviour of previously used LAYMAN_AUTHZ_MODULE:
  • LAYMAN_AUTHZ_MODULE=layman.authz.read_everyone_write_owner (variable to remove)
    • GRANT_CREATE_PUBLIC_WORKSPACE= (new variable)
    • GRANT_PUBLISH_IN_PUBLIC_WORKSPACE= (new variable)
  • LAYMAN_AUTHZ_MODULE=layman.authz.read_everyone_write_everyone (variable to remove)
    • GRANT_CREATE_PUBLIC_WORKSPACE=EVERYONE (new variable)
    • GRANT_PUBLISH_IN_PUBLIC_WORKSPACE=EVERYONE (new variable)
• Change LAYMAN_CLIENT_VERSION to v1.4.1
  • If you are running Layman with development settings, run also make client-build.
• Starting version 1.8, each user can have zero or one personal workspaces, not more (in other words, one Liferay account can be linked with zero or one personal workspaces). Layman automatically checks this at first start. If two workspace linked to single user are fond, they are reported and Layman initialization is stopped. In such case, choose which one of reported workspaces should be the only personal workspace of the user, delete authn.txt file from the other workspace, and restart layman. The other workspace becomes public.
• If you are running Layman with development settings, run also make timgen-build.

Changes

• We started to strictly distinguish workspace as place, where publications are stored, and user as representation of person in Layman system. This change was reflected in following places:
  • In REST API documentation, username was replaced with workspace_name. It's not breaking change, as it's only naming of part of URL path.
  • Error messages and data, as well as Layman Test Client, also distinguishes workspace and user/username.
• Each workspace is now either personal, or public. Personal workspace is automatically created when user reserves his username. Creation of and posting new publication to public workspaces is controlled by GRANT_CREATE_PUBLIC_WORKSPACE and GRANT_PUBLISH_IN_PUBLIC_WORKSPACE.
• #28 It is possible to control also read access to any publication per user.
  • New attribute access_rights added to GET Layers, GET Layer, GET Maps and GET Map responses.
  • New parameters access_rights.read and access_rights.write added to POST Layers, PATCH Layer, POST Maps and PATCH Map requests. These new parameters are added to Test Client GUI.
  • Default values of access rights parameters (both read and write) of newly created publications are set to current authenticated user, or EVERYONE if published by anonymous.
• #28 At first start of Layman, access rights of existing publications are set in following way:
  • everyone can read and only owner of the workspace can edit publications in personal workspaces
  • anyone can read or edit publications in public workspaces.
  • Security rules on GeoServer on workspace level (workspace.*.r/w) are deleted and replaced with security rules on layer level (workspace.layername.r/w) according to rules on Layman side.
• #28 Only publications with read access for EVERYONE are published to Micka as public.
• #28 New REST endpoint GET Users with list of all users registered in Layman. This new endpoint was added to Test Client into tab "Others".
• #28 WMS endpoint accepts same authentication credentials (e.g. OAuth2 headers) as Layman REST API endpoints. It's implemented using Layman's WFS proxy. This proxy authenticates the user and send user identification to GeoServer.
• #161 New method DELETE was implemented for endpoints DELETE Maps and DELETE Layers.
• #178 New attribute screen_name is part of response for GET Users and Get Current User.
• #178 LifeRay attribute screen_name is preferred for creating username in Layman. Previously it was first part of email.
• Attribute groups is no longer returned in GET Map File response.
• #28 New environment variable LAYMAN_PRIME_SCHEMA.

v1.7.4

Changes

• #175 Fix posting new layer caused by v1.7.3.

v1.7.3

⚠️ Attention ⚠️

There is a critical bug in this release, posting new layer breaks Layman: #175 It's solved in v1.7.4.

Changes

• If published layer has empty bounding box (i.e. no features), its bounding box on WMS/WFS endpoint is set to the whole World. This happens on POST Layers and PATCH Layer.
• #40 Enable to upload empty ShapeFile.

v1.7.2

Changes

• #133 Attribute url of GET Maps response was repaired. Previously, it incorrectly used map name instead of username in the URL path.

v1.7.1

Upgrade requirements

• Change LAYMAN_CLIENT_VERSION to v1.3.0
  • If you are running Layman with development settings, run also make client-build.

Changes

• Test Client contains also GET Layer Style endpoint.
• Return real SLD style in GET Layer Style instead of just metadata
• #109 Handle records without title in GET Layers / GET Maps

v1.7.0

Upgrade requirements

• #65 Set environment variable LAYMAN_GS_AUTHN_HTTP_HEADER_ATTRIBUTE. Only combination of lowercase characters and numbers must be used for the value.
• #101 Change LAYMAN_CLIENT_VERSION from v1.1.2 to v1.2.0
  • If you are running Layman with development settings, run also make client-build.

Changes

• #65 WFS endpoint accepts same authentication credentials (e.g. OAuth2 headers) as Layman REST API endpoints. It's implemented using Layman's WFS proxy. This proxy authenticates the user and send user identification to GeoServer. In combination with changes in v1.6.0, Layman's read-everyone-write-owner authorization (when active) is propagated to GeoServer and user can change only hers layers.
• #88 Attribute title was added to REST endpoints GET Layers and GET Maps.
• #95 When calling WFS Transaction, Layman will automatically create missing attributes in DB before redirecting request to GeoServer. Each missing attribute is created as VARCHAR(1024). Works for WFS-T 1.0, 1.1 and 2.0, actions Insert, Update and Replace. If creating attribute fails for any reason, warning is logged and request is redirected nevertheless.
• #96 New REST API endpoint Layer Style is created, which returns Layer default SLD. New attribute sld.url is added to GET Layer endpoint, where URL of Layer default SLD can be obtained. It points to above mentioned Layer Style.
• #101 Test Client has new page for WFS proxy and is capable to send authenticated queries.
• #65 Layman automatically setup HTTP authentication attribute and chain filter at startup. Secret value of this attribute can be changed in LAYMAN_GS_AUTHN_HTTP_HEADER_ATTRIBUTE and is used by Layman's WFS proxy.

v1.6.1

#97 Before v1.6, reserved username could be the same as LAYMAN_GS_USER. Starting at 1.6, this leads to conflict of two GeoServer users with the same name. This patch release comes with detection of this conflict (Layman error code 41).

• If you encounter error 41, you can resolve the conflict by following steps:
  • In GeoServer GUI, create new GeoServer user with another name to become new LAYMAN_GS_USER and give him LAYMAN_GS_ROLE and ADMIN roles
  • In GeoServer GUI, remove the old LAYMAN_GS_USER user
  • Change environment settings LAYMAN_GS_USER and LAYMAN_GS_PASSWORD for the new GeoServer user
  • Restart Layman

v1.6.0

Upgrade requirements

• #69 If you are running Layman with development or test settings, set LAYMAN_SETTINGS_MODULE in your .env file to layman_settings. No action is required if you are running Layman based on demo settings (probably all production instances).

Changes

• #74 Layman user and role at GeoServer defined by LAYMAN_GS_USER and LAYMAN_GS_ROLE are now created automatically on Layman's startup if an only if new environment variable GEOSERVER_ADMIN_PASSWORD is provided. There is no need to set GEOSERVER_ADMIN_PASSWORD for other reason than automatically creating Layman user and Layman role.
  • No change is required. If you are migrating existing instance, Layman user and role are already created, so you don't need to set GEOSERVER_ADMIN_PASSWORD. If this is your first Layman release, GEOSERVER_ADMIN_PASSWORD is set in .env files starting with this version, so Layman user and role at GeoServer will be automatically created on startup.
  • No need to run command make geoserver-reset-default-datadir from now on. This command was removed from make options.
• #62 GeoServer Proxy Base URL is now automatically set on Layman's startup according to LAYMAN_GS_PROXY_BASE_URL. If you do not set the variable, value is calculated as LAYMAN_CLIENT_PUBLIC_URL+LAYMAN_GS_PATH. If you set it to empty string, no change of Proxy Base URL will be done on GeoServer side.
• #83 All layers are created as GEOMETRY type, so any other type can be added (for example polygons can be added to points).
• #73 Layman users are automatically created on GeoServer (either at start up of Layman or when reserved) with separate role and workspace. Username is the same as in Layman, name of role is "USER_"+username, name of workspace is the same as username. Read and write permissions for workspace are set according to Layman's authorization (as of now read-everyone-write-everyone or read-everyone-write-owner).
• New environment variables LAYMAN_GS_USER_GROUP_SERVICE and LAYMAN_GS_ROLE_SERVICE enable to control which user/group and role services are used at GeoServer. Not setting these variables means to use default services.
• #69 Three separate identical settings files (layman_settings_demo.py, layman_settings_dev.py, layman_settings_test.py) were merged into one file layman_settings.py.
• If username used in REST API request path is not yet reserved, HTTP requests other than POST returns (e.g. GET) HTTP error 404 (Layman code 40). Previously in case of GET request, empty list was returned.
• List of GeoServer reserved workspace names was moved from layman_settings.py into source code (src/layman/common/geoserver/__init__.py)
• Undocumented authentication module layman.authn.url_path.py that was unused for a long time, was removed.
• Python setting PG_NON_USER_SCHEMAS is now more explicit about forbidden schema names.