Privacy, authentication, and self-hosting GeoLibre for sensitive community data(?)

[rudokemper]

Hi GeoLibre team,

I've been spending some time with GeoLibre recently and have been really impressed by how much it has developed. I'm working on an open-source platform called Guardian Connector, which we build with Indigenous and other local communities to help them privately host, manage, analyze, and use their own monitoring data.

Guardian Connector is deployed as a separate private VM for each organization. Privacy and data sovereignty are pretty fundamental requirements for us: in many cases, spatial data should only be accessible to approved users of that particular community server.

GeoLibre looks potentially very useful as a downstream tool for Guardian Connector users, especially for more exploratory GIS work and for creating outputs like maps and Story Maps. I've been experimenting with loading GeoJSON produced by Guardian Connector into GeoLibre, as well as saving a .geolibre.json project and serving it back to the browser build using ?url=. That all works nicely when the files are publicly accessible.

The part I'm trying to understand is how GeoLibre might fit into an environment where neither the source data nor the GeoLibre project itself can be public.

I can imagine two possible approaches:

1. Host GeoLibre on the community VM. We could deploy the browser version alongside the rest of Guardian Connector and put it behind the same authentication / single sign-on layer we use for other applications. Ideally, GeoLibre could then load datasets and .geolibre.json projects that are also hosted on that VM and only accessible to authenticated users.

2. Use a GeoLibre deployment hosted elsewhere, but authenticate access to the project/data. For example, a user might open web.geolibre.app, but the .geolibre.json passed through ?url= would live on a private Guardian Connector server and require some kind of token, authenticated request, or other access mechanism.

Because GeoLibre is client-side, I realize some of this may ultimately be more of an infrastructure question than something GeoLibre itself needs to manage. But I'd be very interested to understand how you think about this use case.

In particular:

• Has private or authenticated access to GeoLibre projects/data come up before?
• Are there limitations we should be aware of when loading authenticated remote resources from the browser build?
• Is any kind of authenticated/private sharing workflow something you have considered for the GeoLibre roadmap?

I'm mainly trying to understand what direction would fit best with GeoLibre's architecture before we experiment too far down one path. It may well be that the most appropriate model is simply to treat GeoLibre similarly to QGIS: as a tool users can work with after downloading data from Guardian Connector. In the case of GeoLibre Desktop, I understand that its bundled Martin tile server could also provide a path for working directly with PostGIS data, much as a user might connect QGIS directly to a database. But if there is a sensible way to support a more integrated, authenticated browser-based workflow, we'd be very interested in understanding what that could look like.

Thanks, and really nice work on GeoLibre. It's been fun to explore!

[giswqs]

@rudokemper Thank you for your interest in GeoLibre. Those are great questions. I recommendation is to use GeoLens for self-hosting data with gated access and use GeoLibre for accessing and visualizing data. GeoLibre has native support for GeoLens (Plugins - Web Services - GeoLens). More information can be found at https://geolibre.app/self-hosting.

Alternatively, you can develop a GeoLibre plugin to access your custom data catalogs with auto activation. Place the plugin under GeoLibre/apps/geolibre-desktop/public/plugins/

[rudokemper]

Thanks for your quick response and putting together documentation, @giswqs! We will evaluate the approaches.

[giswqs]

@rudokemper I just added an optional Clerk sign-in gate, making it much easier to control access to the app. See https://geolibre.app/getting-started/#clerk-sign-in-gate-optional

You can test it at https://studio.geolibre.app

[rudokemper]

Thanks @giswqs. We use auth0 for our stack (primarily because many third party apps that we deploy are integrated with auth0), but nice to see the Clerk integration. I actually hadn't heard of Clerk before so I learned a bit from exploring the links.

[giswqs]

Auth0 is now supported. See https://geolibre.app/getting-started/?h=auth#auth0-sign-in-gate-optional