GeoServer 2.25.7 release is now available with downloads (bin, war, windows), along with docs and extensions.

This series has previously reached end-of-life, with this release issued to address an urgent bug or security vulnerability. Please apply this update as a mitigation measure only, and plan to upgrade to a stable or maintenance release of GeoServer. GeoServer 2.25.7 is made in conjunction with GeoTools 31.7.

Thanks to Jody Garnett and Andrea Aime (GeoSolutions) for making this release.

Security Considerations

This release addresses security vulnerabilities and is considered an critical update.

• CVE-2025-30220 XML External Entity (XXE) Processing Vulnerability in GeoServer WFS Service (High)

• CVE-2025-30145 Denial-of-service (DoS) Vulnerability in Jiffle process (High)

The use of the CVE system allows the GeoServer team to reach a wider audience than blog posts. See project security policy for more information on how security vulnerabilities are managed.

Release notes

Improvement:

Bug:

• GEOS-11774 Logout with OAuth plugin will give error if logged in locally

Task:

• GEOS-11770 Update to jai-ext 1.1.31

For the complete list see 2.25.7 release notes.

Community Updates

Community module development:

• GEOS-11762 Feature Templates by feature type can not be listed via GeoServer Rest API
• GEOS-11783 Longitudinal profile process should allow for input chaining
• GEOS-11784 The longitudinal profile process should limit the number of points it can extract
• GEOS-11785 The longitudinal profile process should respect cancellation
• GEOS-11786 Longitudinal profile process: general performance improvements
• GEOS-11811 Features templating editor is unable to update and save the template body

Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.

About GeoServer 2.25 Series

Additional information on GeoServer 2.25 series:

• GeoServer 2.25 User Manual
• GeoServer 2024 Roadmap Plannings
• Raster Attribute Table extension
• Individual contributor clarification

Release notes: ( 2.25.7 | 2.25.6 | 2.25.5 | 2.25.4 | 2.25.3 | 2.25.2 | 2.25.1 | 2.25.0 | 2.25-RC )

The GeoServer team is charging ahead with our 2025 roadmap plans.

Thanks to 2025 Sponsors:

CITE Certification

A great deal of progress has been made on CITE Certification with the most recent GeoServer 2.27.0 Release passing tests! This is great for interoperability and project stability as the CITE tests act as an external “blackbox” testing framework and this verifies that GeoServer is operating as intended.

We are presently determining how to pay for certification:

• The Open Source Geospatial Foundation has negotiated a reduced rate of $150 annual cost per standard certified.
• We are prioritizing tests where we can act as a “reference implementation” resulting in no annual cost for OSGeo.
• For Web Feature Service we pass tests for WFS 2.0, WFS 1.1, and WFS 1.0 which would add up to $450. It may be worthwhile only being certified for the latest WFS 2.0 to reduce the costs to $150.
• There are also now CITE tests for output formats. This would allow the WFS and WPS output to be certified on individual formats like GeoPackage and GeoTIFF.

While GeoServer presently “implements” these standards, our sponsorship level is not sufficient to allow us to feel comfortable paying annual costs for “certification”.

Full certification amounts to $900 a year, while certifying only the latest services amounts to $450 a year.

How you can help: We would really like confirmation that certification is valuable to the community. If you think it is valuable, please let us know in the Discourse forum or, even better, if you are interested in sponsoring part of the certification, please do speak up! If we do not hear from anyone, we might not pursue formal certification any further.

Many thanks to prior sponsors of this activity including Gaia3D, and OSGeo:UK.

GeoServer 3

The big news is that GeoServer 3 crowdfunding campaign phase one has been successful, allowing the project plan milestones to be scheduled.

We are working around the GeoServer release schedule to avoid disruption to the project:

• Milestone 1 : Preparation (May-September)
  Doing everything possible ahead of time before the migration to spring-framework-6.

  Milestone 1 is already in progress, see the headings below for specific activities.

  Milestone 1 activities will be taking place on the main branch ahead of the GeoServer 2.28 release. As tasks are completed, your feedback and continuous testing of nightly builds will be highly appreciated. Please chat to us about how you can automate the testing in your non-production environments.

• Milestone 2 : Migration (October-December)
  Requires a coordinated “code-freeze” across nine codebases migrating to spring-framework-6.

  This activity is going to take careful planning, and we anticipate scheduling an in-person sprint for the migration.

  While initial work may occur on a dev branch, GeoServer 3 will take over the main branch after the September release of GeoServer 2.28.0.

• Milestone 3: Delivery (January-March)
  The moment we have the code-base working again, Milestone 3 activities include continuing the testing of nightly builds, checking integration with downstream applications, and feedback from anyone wishing to work on restoring a community module to GeoServer 3.

  This pace allows GeoServer 3.0 to be ready in 2026 Q1, respecting our normal time-boxed release cycle.

Milestone 1

Checking in on Milestone 1 activities, there is lots of work to be done!

Spring Framework Preparation, Java 17, and Project and Build Support

To get the codebase ready for widespread change, Gabriel will be looking at setting up a GeoTools “bill of materials” pom.xml file providing GeoServer and other applications an easy way to manage the currently tested set of dependencies.

• Updating to Java 17 is a key requirement for Spring Framework 6 and JakartaEE so expect many of these dependencies to be updated or replaced over the course of GeoServer 2.28 development.
• Spring Framework 6 also removes a lot of deprecated APIs and dependencies, providing work to do for GeoWebCache and GeoServer codebases

ImageN and JAI-Ext Online Sprint (May 26-27)

The biggest GeoServer 3 Milestone 1 activity is restarting the ImageN project and combining forces with JAI-Ext for a new image processing engine:

• ImageN represents the Oracle donation of the original Java Advanced Imaging codebase to the Eclipse Foundation (using a new name that does not contain “Java”).
• The ImageN project is being restarted, with Andrea and Daniele being recently added to the project.
• Project website has been updated with a slightly revised scope to reflect the addition of the JAI-Ext codebase.
• We will be cutting some unused functionality, such as RMI, and restructuring the maven build to reflect some of the lessons learned with JAI-Ext and GeoTools build practices.
• Andrea has a rough project plan which we will capture as a project board in the weeks ahead.
• Communication is taking place over on the imagen-dev mailing list.

Andrea and Jody are organizing an ImageN Online Sprint for May 26-27 where the bulk of the work will take place. We plan to follow the same approach as the OpenGIS Harmonization activity where refactor scripts are produced, and tested on the GeoTools / GeoWebCache / GeoServer codebases during development.

Spring Security and OAuth2 / OIDC Security Modules

The next technical challenge is the work needed to update to the next version (6) of the Spring Security Framework. There have been considerable API changes, resulting in the need to completely replace the existing OAuth2 and OIDC community modules. Our existing community modules are based on the deprecated spring-security-oauth library which has now reached end of life. The Spring Security Core library now has OAuth2 support, necessitating a new GeoServer extension that makes direct use of the built-in OAuth2 support.

Andreas Watermeyer (ITS Digital Solutions) has working on these activities:

• GeoServer 2.27.0 includes the upgrade to Spring Security 5.8, and there is a checklist to complete before upgrading further to version 6.
• Andreas has a draft pull request re-implementing the OAuth2 security modules, which we are looking forward to incorporating, and we plan to port all the test cases over to ensure that it covers the same functionality.

Ideally GeoServer 2.28.0 will include both the old and the new Spring Security OAuth2 community modules, allowing everyone to upgrade easily and report back any regressions found.

Wicket

A big accomplishment in the recent GeoServer 2.27.0 Release is progress towards Wicket 10 by Brad and David:

• Wicket 9
• Wicket Dialog
• Wicket Content Security Policy

There are a few remaining items to work on, such as the Java 17 build, before upgrading to Wicket 10.

It is great that we have already tackled many of the technical challenges above, and have received positive responses from GeoServer 2.27.0 testers.

Crowdfunding

GeoServer 3 crowdfunding has completed the Commitment Phase - thank you for your trust and support. We are now contacting supporters to engage with them further.

GeoServer 3 is supported by the following organisation:

Individual donations: Abhijit Gujar, Hennessy Becerra, Ivana Ivanova, John Bryant, Jason Horning, Peter Smythe, Sajjadul Islam, Sebastiano Meier, Stefan Overkamp.

The GeoServer 3 crowdfunding campaign is now entering its final phase. After months of effort and strong engagement from the geospatial community, we are approaching our collective goal. The campaign has reached over 90% of its target, with only €40,000 remaining. Several organizations are currently engaged in discussions, and we remain confident that we will successfully complete the campaign.

📅 We will officially close the campaign on Monday, April 21, 2025.
This is the final window of opportunity for organizations that wish to contribute and ensure GeoServer’s continued innovation and reliability.

Why this upgrade is critical

GeoServer 3 is more than just a version number—it is a significant technical shift that will modernize the platform’s foundations and secure its future. This includes:

• Migration to Spring 6 and JDK 17: Required to maintain compatibility with modern Java ecosystems, ensure long-term support, and adopt secure, future-proof components.
• End of support for Spring 5: From January 2025, no more security updates will be provided, making the upgrade essential for compliance and operational security.
• OAuth2 support and improved security architecture: Crucial for enterprise-grade authentication and integration with modern infrastructure.
• Switch from JAI to ImageN: A much-needed replacement for image processing, improving speed, maintainability, and compatibility.
• Alignment with current deployment environments: Including Tomcat 10 and Jakarta EE, ensuring compatibility with containerized and cloud-native environments.

You can learn more about the technical transition already underway in this behind-the-scenes update.

What happens if we exceed the goal?

If the total contributions exceed the financial target, the additional workforce funded through this campaign will be redirected to tasks identified and prioritized by the GeoServer Project Steering Committee (PSC). This ensures the extra support directly benefits the project’s long-term roadmap and the broader user community.

Acknowledgements and next steps

We extend our sincere thanks to all who have supported this campaign so far—through funding, code contributions, testing, and outreach. The effort has already mobilized an international team of core contributors who are ready to move forward.

We now invite all remaining stakeholders to join before the deadline. If your organization uses GeoServer and values its open, sustainable evolution, this is your moment to act.

🔗 To pledge or contact the coordination team, please visit:
https://geoserver.org/sponsor/gs3-crowdfunding

Let’s complete this journey—together.

GeoServer 3 is supported by the following organisation:

Individual donations: Abhijit Gujar, Hennessy Becerra, Ivana Ivanova, John Bryant, Jason Horning, Peter Smythe, Sajjadul Islam, Sebastiano Meier, Stefan Overkamp.

GeoSpatial Techno is a startup focused on geospatial information that is providing e-learning courses to enhance the knowledge of geospatial information users, students, and other startups. The main approach of this startup is providing quality, valid specialized training in the field of geospatial information.

( YouTube | LinkedIn | Facebook | X )

Mastering WFS Transactions in GeoServer: A Comprehensive Guide

In this session, we’ll explore WFS transactions available in GeoServer. If you want to access the complete tutorial, click on the link.

Introduction

The Web Feature Service (WFS) transactions in GeoServer, enable users the ability to manipulate geographic data for serving and editing geospatial information over the web. This feature allows for direct editing of spatial features within a dataset through a web browser or application, without needing to download and edit the data locally.

WFS transactions in GeoServer allow users to dynamically edit spatial data by sending XML requests to insert, update, or delete features. This real-time editing is crucial for applications like online maps and collaborative planning systems. It improves efficiency, data accuracy, and supports real-time collaboration.

Note. This video was recorded on GeoServer 2.22.4, which is not the most up-to-date version. Currently, versions 2.25.x and 2.26.x are supported. To ensure you have the latest release, please visit this link and avoid using older versions of GeoServer.

Note. In all examples in this blog post, we utilize the topp:tasmania_roads layer.

WFS Insert Feature

The Insert Feature operation, when used with GeoServer’s WFS transaction feature, allows users to append new features to an existing dataset. This ensures the new feature is securely added to the layer, preventing data duplication and errors.

Note. Backup your data and configuration before making any changes to avoid potential data loss or unexpected behavior.

Here is an example of how to use the WFS insert feature in GeoServer:

• Navigate to the Demos page, then click on the Demo requests link.
• From the Request drop-down list, select WFS_transactionInsert.xml.

• Enter the new coordinates and road’s type as follows:

  <wfs:Insert>
    <topp:tasmania_roads>
      <topp:the_geom>
        <gml:MultiLineString srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
          <gml:lineStringMember>
            <gml:LineString>
              <gml:coordinates decimal="." cs="," ts=" ">
                145.2,-42.5 145.2,-43.3 145.8,-43.3
              </gml:coordinates>
            </gml:LineString>
          </gml:lineStringMember>
        </gml:MultiLineString>
      </topp:the_geom>
      <topp:TYPE>street</topp:TYPE>
    </topp:tasmania_roads>
  </wfs:Insert>
  

• Remember that using the WFS transaction in GeoServer requires appropriate permissions and access rights to ensure that only authorized users can modify the data. Enter the username and password to be authorized, and then press the Submit button.
• GeoServer processes the transaction request. If successful, it adds the new feature to the road layer; if unsuccessful, a relevant error information is displayed and no changes are made to the data.
• Navigate to the Layer Preview section and open up the OpenLayers preview for the tasmania_roads layer. Your map should now look like this:

You have successfully used the insert feature with WFS transaction in GeoServer to add a new street to your dataset.

WFS Update Feature

The Update feature of the WFS transaction in GeoServer enables users to modify existing features within a geospatial dataset. By submitting a request that specifies both the feature type and the desired changes to attributes and geometry, users can efficiently update specific attributes while altering the shape, location, and size of various features.

Here are the steps to perform an update feature with WFS transaction in GeoServer:

• Select WFS_transactionUpdateGeom.xml from the Request drop-down list, then edit the codes as follows:

  <wfs:Update typeName="topp:tasmania_roads">
    <wfs:Property>
      <wfs:Name>the_geom</wfs:Name>
      <wfs:Value>
        <gml:MultiLineString srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
          <gml:lineStringMember>
            <gml:LineString>
              <gml:coordinates>145.55,-42.7 145.04,-43.04 145.8,-43.4</gml:coordinates>
            </gml:LineString>
          </gml:lineStringMember>
        </gml:MultiLineString>
      </wfs:Value>
    </wfs:Property>
    <ogc:Filter>
      <ogc:FeatureId fid="tasmania_roads.15"/>
    </ogc:Filter>
  </wfs:Update>
  

• Enter the username and password to be authorized, and then press the Submit button.
• After the GeoServer has processed the transaction request, go back to the Layer Preview section and open up the OpenLayers preview for the tasmania_roads layer. Your map should now look like this:

WFS Delete Feature

This operation allows users to selectively remove specific features from a dataset by providing their unique identifiers. The process of deleting features can be seamlessly executed through the WFS transaction capabilities in GeoServer.

This functionality gives users more control over their geospatial database, helping them manage and manipulate data efficiently. As an example, let’s remove the features whose type attribute is equal to road. To do this, follow the steps displayed on the screen:

• Select WFS_transactionDelete.xml from the Request drop-down list, then edit the codes as follows:

  <wfs:Delete typeName="topp:tasmania_roads">
    <ogc:Filter>
      <ogc:PropertyIsEqualTo>
        <ogc:PropertyName>topp:TYPE</ogc:PropertyName>
        <ogc:Literal>road</ogc:Literal>
      </ogc:PropertyIsEqualTo>
    </ogc:Filter>
  </wfs:Delete>
  

• Enter the username and password to be authorized, and then press the Submit button.
• After the GeoServer has processed the transaction request, preview for the tasmania_roads layer. As you can see, the features of type Road have been deleted.

Remember that you can define filter conditions to remove the specific features using the WFS Delete transaction. This can include feature IDs, attributes, spatial extent or other criteria.

• Again, select WFS_transactionDelete.xml from the Request drop-down list, then edit the codes as follows:

  <wfs:Delete typeName="topp:tasmania_roads">
    <ogc:Filter>
      <ogc:FeatureId fid="tasmania_roads.15"/>
    </ogc:Filter>
  </wfs:Delete>
  

• Enter the username and password to be authorized, and then press the Submit button.
• After the GeoServer has processed the transaction request, open the OpenLayers preview for the tasmania_roads layer from the Layer Preview section. As you can see, the fid 15 has been deleted.

In this session, we took a brief journey to explore WFS Transaction to insert update and remove features in GeoServer. If you want to access the complete tutorial, click on the link.

GeoServer 2.27.0 release is now available with downloads (bin, war, windows), along with docs and extensions.

This is a stable release of GeoServer recommended for production use. GeoServer 2.27.0 is made in conjunction with GeoTools 33.0, GeoWebCache 1.27.0, and ImageIO-EXT 1.4.15.

This release graduates the OGC API Features module to extension status, ensures all OGC services pass CITE compliance tests, and adds performance improvements to the catalog loader that significantly reduces startup times for large deployments. The release also includes Smart Data Loader override rules. This release addresses several security vulnerabilities, and enforces browser Content Security Policy for increased security.

Thanks to extensive community testing through our user forum, we’re confident in recommending this release for production use. Check update notes for specific instructions.

Thanks to Gabriel Roldan (Camptocamp) and Jody Garnett (GeoCat) for making this release and to all contributors who helped with this release cycle.

Community Testing

This release cycle featured an extensive community testing effort, with our new discourse communication channels playing a central role in pre-release validation.

Testers helped identify and resolve several important issues:

• Performance Improvements: Daniel Calliess verified faster startup times and validated the GeoFence plugin functionality.
• Security Enhancements: Georg and Roar Brænden provided detailed feedback on the new Content Security Policy (CSP) implementation, helping refine the upgrade instructions.
• Catalog Robustness: Andrea tested the new parallel catalog loader across various data directory configurations, identifying and helping resolve concurrency edge cases.
• Documentation: Emanuele Tajariol collaborated with Daniel to update GeoFence plugin documentation.
• Standards Implementation: Landry Breuil validated the OGC API Features extension on behalf of the geOrchestra community.

The GeoServer team is grateful to all community members who participated in this testing effort. Their feedback was instrumental in addressing issues before release and ensuring a smooth upgrade experience for users.

Special thanks to Andrea, Jody, Peter, and Gabriel for their diligent work reviewing feedback and addressing issues throughout the preflight testing period.

Security Considerations

This release addresses several security vulnerabilities, and is a recommended upgrade for production systems.

• CVE-2025-30145 Denial-of-service (DoS) Vulnerability in Jiffle process (High)
• CVE-2025-27505 Missing Authorization on REST API Index (Moderate)
• CVE-2024-29198 Unauthenticated SSRF via TestWfsPost (Moderate)
• CVE-2024-40625 Coverage REST API Server Side Request Forgery (Moderate)

The use of the CVE system allows the GeoServer team to reach a wider audience than blog posts. See project security policy for more information on how security vulnerabilities are managed.

OGC API FeaturesService Extension

The OGC API Features module has officially graduated from community status to become a supported GeoServer extension. This implementation of the modern, web-friendly OGC API - Features standard provides a RESTful API alternative to traditional WFS services.

Key capabilities include:

• Feature collection discovery and access
• Spatial and attribute filtering using CQL2
• Multiple output formats (GeoJSON, HTML, etc.)
• Service-level operations across multiple collections

This service operates alongside the existing WFS services:

1. Update the WFS Settings title and description appropriately.

   

2. This information is used for the service landing page:

   

3. GeoServer has not previously included draft or work-in-progress development - preferring to make such functionality available as community modules for developers to collaborate. However OGC API - Features specification is defined in a modular fashion, and accommodates the idea of both draft and community standards.

   To configure enable/disable “conformances” for Features, CQL2, and ECQL.

   

4. For more information on OGC API support in GeoServer:

   • OGC API Service Configuration (User Manual)
   • Configuration of OGC API - Features module (User Manual)

This graduation is the result of a collaborative code sprint with developers from Camptocamp, GeoSolutions, and GeoCat joining forces. As part of this effort, the module now passes OGC CITE compliance tests, ensuring proper interoperability with other OGC-compliant systems.

Special thanks to the French “Commissariat général au développement durable du Ministère chargé de l’Ecologie” for sponsoring this work as part of the Collectif Interopérabilité et mise en Commun de Composants Logiciels pour les plateformes de données (CICCLO) project.

For more information, and the extension user docs.

• GSIP-230 OGC API Features Extension
• GEOS-11627 OGCAPI FeatureService Extension

OGC CITE Compliance

A significant effort has been made to ensure GeoServer passes the OGC Conformance and Interoperability Test and Evaluation (CITE) compliance tests across all supported services. This work improves the quality and interoperability of GeoServer with other OGC-compliant systems.

Restoring CITE Compliance has been a project goal for a number of years, and an ongoing sponsorship goal for the GeoServer project. Many thanks to prior sponsors of this activity including Gaia3D, and OSGeo:UK.

We are pleased to share that GeoServer now passes all the OGC CITE compliance tests available for the services it supports. Passing OGC CITE tests involved fixing numerous issues related to exception handling, version negotiation, and service behavior.

Special thanks to Andrea Aime for leveraging, extending, and improving the OGC CITE conformance testing infrastructure that was developed during the OGC API Features work, and methodically applying it to ensure all GeoServer services now pass their respective compliance tests.

While official certification from the OGC is still pending at the time of writing, the process is underway and we anticipate formal recognition of GeoServer in the coming days.

Thanks to Peter Smythe (AfriGIS) and Angelos Tzotsos for working with Open Source Geospatial Foundation to provide access to the CITE Certification process. Once certification is granted, we will update this post and home page with a “live logo” to reflect our official status.

• GEOS-11729 Pass WCS 1.0 certification OGC CITE tests
• GEOS-11730 Pass WCS 1.1 certification OGC CITE tests
• GEOS-11780 Pass WCS 2.0 certification OGC CITE tests
• GEOS-11731 Pass WFS 1.0 certification OGC CITE tests
• GEOS-11732 Pass WFS 1.1 certification OGC CITE tests
• GEOS-11733 Pass WFS 2.0 certification OGC CITE tests
• GEOS-11734 Pass WMS 1.1 certification OGC CITE tests
• GEOS-11735 Pass WMS 1.3 certification OGC CITE tests
• GEOS-11779 Pass WMTS 1.0 certification OGC CITE tests
• GEOS-11736 Pass OGC API Features 1.0 certification OGC CITE tests
• GEOS-11752 Pass GeoTIFF 1.1 certification OGC CITE tests
• GEOS-11753 Pass GPKG 1.2 certification OGC CITE tests

Content Security Policy Enforced

The use of Content Security Policy (CSP) headers is an additional safety precaution introduced by your browser to mitigate cross-site scripting and clickjacking attacks.

GeoServer 2.27.0 pages now include a Content Security Policy, limiting expected browser interactions to increase security.

• Before updating double check your PROXY_BASE_URL setting is correct.

  This is a common mistake blocked by the new CSP policy.

• It is expected that the web administration console functions correctly, along with extensions and community modules.

  With these improved CSP safety measures GeoServer may now detect vulnerabilities in your environment that were previously undetected.

  If you run into any problems, troubleshooting instructions are available in the user manual.

• Additional tools are available for administrators seeking greater control.

  

Thanks to Steve Ikeoka for his dedication to this activity.

• GSIP 227 Content-Security-Policy Headers
• GEOS-11346 Add a configurable Content-Security-Policy header
• GEOS-11698 Update GeoServer User Interface Troubleshooting Guidance
• GEOS-11585 Patch Spectrum to work with Wicket’s CSP
• GEOS-11586 Patch CodeMirror to work with Wicket’s CSP
• GEOS-11669 Patch jscolor to work with Wicket’s CSP

Faster Catalog Loading

GeoServer 2.27.0 includes significant performance improvements for server startup with the promotion of the “datadir catalog loader” from a community module to the GeoServer core. This enhanced loader dramatically improves startup times for deployments with large data directories through parallel processing.

The performance gains are substantial, as shown by these benchmark results:

NFS/10Gbps Storage:

• 16K layers: reduced from 5.8s to 3.3s (1.8× faster)
• 100K layers: reduced from 1.9min to 28.3s (4.1× faster)
• 1M layers: reduced from 21.3min to 5.9min (3.6× faster)

NVMe Gen5/ZFS Storage:

• 16K layers: reduced from 3.5s to 1.3s (2.7× faster)
• 100K layers: reduced from 21.2s to 3.2s (6.5× faster)
• 1M layers: reduced from 3.4min to 24.6s (8.3× faster)

The new loader uses work-stealing thread pools for catalog processing while ensuring thread safety. This enhancement is particularly valuable for large enterprise deployments where startup time has been a bottleneck.

The loader is enabled by default but can be disabled or tuned if needed as explained in the data directory documentation.

• GSIP-231 Promote data_dir catalog loader to core
• GEOS-11284 Promote community module “datadir catalog loader” to core

File System Sandbox Isolation

A file system sandbox is used to limit access for GeoServer Administrators and Workspace Administrators to specified file folders.

• A system sandbox is established using GEOSERVER_FILESYSTEM_SANDBOX application property, and applies to the entire application, limiting GeoServer administrators to the <sandbox> folder, and individual workspace administrators into isolated <sandbox>/<workspace> folders.

• A regular sandbox can be configured from the Security > Data screen, and is used to limit individual workspace administrators into <sandbox>/<workspace> folders to avoid accessing each other’s files.

  

Thanks to Andrea (GeoSolutions) for this important improvement at the bequest of Munich RE.

• GSIP 229 - File system access isolation
• File system sandboxing (User Manual)

MapML Enhancement

The MapML extension continues to receive significant updates.

Tiled Coordinate Reference Systems can now be managed with a new MapML TCRS Settings page, available in the Admin Console Settings section:

The MapML TCRS Settings page provides a selector containing available GridSets. The administrator can select GridSets from the left list that will be converted to TiledCRSs.

Check out the documentation for more insights.

These changes provide better integration and more powerful capabilities for creating web maps with MapML.

• GEOS-11561 Client-Delegating MapML Proxy
• GEOS-11577 Rename MapML <layer-> to <map-layer>, rename viewer bundle to mapml.js
• GEOS-11605 MapML Support custom TCRS projections from existing GridSets
• GEOS-11666 Update MapML viewer to latest release 0.16.0

Smart Data Loader Enhancements

The Smart Data Loader has been improved with override rules, making it more flexible for data management scenarios:

The Smart Data Loader plugin automates the creation of XSD schemas and App-Schema mapping files, significantly simplifying the configuration of complex feature data in GeoServer.

With the new override rules capability, you can now customize how database tables are mapped to feature types without modifying the database schema, providing greater control and flexibility when working with complex or legacy data structures.

For more details on using Smart Override Rules, see the official documentation.

• GEOS-11741 Enhancing Smart Data Loader with Override Rules
• GEOS-11691 Smart data loader accepts bigint and bigserial but not int8 postgresql type alias

GeoFence Improvements

The GeoFence extension has received several significant improvements:

These improvements make GeoFence more flexible and powerful for implementing fine-grained security policies.

• GEOS-11702 GeoFence: major libs update
• GEOS-11704 GeoFence: filter rule list by IP address
• GEOS-11705 GeoFence: make rules valid within a date range
• GEOS-11526 GeoFence: slow GeoServer response when there are many roles and layergroups

Performance Improvements

Several performance improvements have been implemented in this release:

• GEOS-11580 Improve embedded GWC meta-tiling performance
• GEOS-11766 Speed up CRS and store factory lookups during catalog loading
• GEOS-11722 Coverage view reader partially ignores multithreaded loading
• GEOS-11739 Excessive memory usage for WMS KML output format
• GEOS-11760 Fix a potential OOM in the KML transformation

WPS Improvements

Several improvements have been made to the Web Processing Service implementations:

• GEOS-11564 WPS calls to internal WFS will handle requests with version=2.0.0
• GEOS-11783 Longitudinal profile process now allows for input chaining
• GEOS-11784 The longitudinal profile process limits the number of points it can extract
• GEOS-11785 The longitudinal profile process now respects cancellation
• GEOS-11786 General performance improvements for the longitudinal profile process

Other Improvements

• GEOS-11468 Coverage REST API URL Checks
• GEOS-11562 Default Gzip filter setting in web.xml does not compress application/javascript
• GEOS-11578 WMTS Multidim extension, allow usage of a sidecar in a separate store
• GEOS-11603 KML download mode now shows layer titles
• GEOS-11612 Add system property support for Proxy base URL -> use headers activation
• GEOS-11613 Increase control-flow logging admin visibility in logs
• GEOS-11624 Split Geopackage extension into separate modules to reduce dependencies
• GEOS-11625 Add “Challenge Anonymous Sessions” Option to AuthKey Filter
• GEOS-11645 Control FreeMarker template access
• GEOS-11654 Fix multiline strings that are missing a space between the lines
• GEOS-11677 Hide version info on GWC home page

Library Updates

GeoServer 2.27.0 includes updates to many core libraries:

• GEOS-11770 Update to jai-ext 1.1.31
• GEOS-11771 Update to Imageio-EXT 1.4.15
• GEOS-11590 Upgrade log4j to 2.24.1 and slf4j to 2.0.16
• GEOS-11608 Update Bouncy Castle Crypto package from bcprov-jdk15on:1.69 to bcprov-jdk18on:1.79
• GEOS-11609 Bump XStream from 1.4.20 to 1.4.21
• GEOS-11685 Bump jetty.version from 9.4.56.v20240826 to 9.4.57.v20241219
• GEOS-11631 Update MySQL driver to 9.1.0
• GEOS-11743 Upgrade Oracle JDBC driver (ojdbc) from 8 to 11
• GEOS-11754 Update to mapfish-print-v2 2.3.3
• GEOS-11763 Update jai-ext to latest version (1.1.30)

Bug Fixes

Many bugs have been fixed in this release, including:

• GEOS-4533, GEOS-7967 Fixed WPS demo builder chaining issues
• GEOS-11494 WFS GetFeature request with a propertyname parameter fails when layer attributes are customized
• GEOS-11524 CSW: default queryables mapping not generated
• GEOS-11540 OGC API queryables features call not working in JSON
• GEOS-11607 KML WMS GetMap is performing a heavy database load query
• GEOS-11620 Smart Data Loader plugin produces a Mapping file data source definition and tries to establish a connection pool, but fails
• GEOS-11636 Store panels won’t always show feedback in target panels
• GEOS-11649 Welcome page per-layer is not respecting global service enablement
• GEOS-11658 Time editor dumps stack trace in UI if the start or end time values are intervals
• GEOS-11664 Update REST security paths
• GEOS-11667 Make WMTS work in strict cite compliance mode
• GEOS-11668 WMTS home page capabilities link uses 1.1.1 as the version, and the wrong version negotiation approach
• GEOS-11684 GDAL no longer included in Docker image
• GEOS-11762 Feature Templates by feature type can not be listed via GeoServer Rest API
• GEOS-11792 Default Service Capabilities shown on initial start with no workspaces
• GEOS-11796 Deadlocks During GeoServer Startup When Loading Style Group Layer Groups

Community Module Updates

Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.

Community module development:

• GEOS-11651 Support env parametrization on OIDC filter
• GEOS-11781 Community cleanup fall 2024
• Removed abandoned community modules:
  • GEOS-11641 Remove the abandoned community module webservice-test
  • GEOS-11642 Remove the gwc-distributed community module

Full Release Notes

For the complete list of changes, see 2.27.0 release notes.

About GeoServer 2.27 Series

Additional information on GeoServer 2.27 series:

• GeoServer 2.27 User Manual
• GeoServer 2025 Roadmap
• Content-Security-Policy Headers
• OGCAPI Features Extension
• File system access isolation
• Promote data dir catalog loader to core

Release notes: (2.27.0)