Expose the tileset and the SQL queries in dev mode #772

bchapuis · 2023-09-04T20:09:54Z

Solves #766.

Perdjesk · 2023-09-05T08:19:51Z

baremaps-server/src/main/java/org/apache/baremaps/server/TilesetResource.java


 /**
- * A resource that provides access to the tileset.
+ * A resource that provides access to the tileset file. Only suitable for development purposes, as
+ * it exposes SQL queries.


IIRC it exposes the database JDBC URL with credentials as well. Basically anything consumed by baremaps for its internal ends up deserialized in Tileset.

@Perdjesk Good point, I just hid the jdbc url. We need to find a good balance between security and usability for the dev mode

Did a draft implementation that reverse the logic in order to allow fields instead of having to disallow them after the facts.
#773

Motivation is similar to what was done in https://github.com/apache/incubator-baremaps/pull/658/files#diff-94ecab9df3004fae4fd05c3c610d8ef629f81cb775f72a53a19070c0293bc27cL62 to remove hiding of field with conditions after de-serialization, which could be error prone for newly added field in tileset.json.

@Perdjesk Thank you for the draft, I understand the motivation. However, I would prefer to keep things as simple and small as possible for now, i.e., to expose the tileset in development and the tileJSON in production.

Sorry, my answer was vague, let's add a bit of context. First, our implementation of tileJSON is partial and I think that adding an extension to the model will slow us down. Second, dev modes are usually insecure and I think it is reasonable to assume that our users will not use it in production. Finally, an earlier version of the dev mode offered a maputnik integration and allowed the user to edit the style. I have not completely abandonned this idea (see #561) and we may introduce an API to edit local files when in dev mode (the security aspects associated with this API still need to be discussed).