Limit client side requests? #473
-
Hello 👋 I would like to ask whether it's possible to apply any kind of rate limiting (or protection) on publicly exposed .pmtiles via maplibre: https://github.com/protomaps/PMTiles/blob/main/js/examples/maplibre.html Adding a server between client and the S3-compatible bucket, e.g. serving the tiles using Martin (https://github.com/maplibre/martin) would be an option, but serving them directly from S3 would result in a more maintenance free solution. Would it be possible to restrict certain users from hammering with GET requests the .pmtiles file? Any ideas would be highly appreciated! Thanks in advance! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
What could also probably prevent hammering is caching. Is tile caching supported on maplibre url pointing to the remote (s3-compatible bucket) .pmtiles file, or should we serve tiles in ZXY format using a tile server like Martin? |
Beta Was this translation helpful? Give feedback.
-
How do you classify rate limiting a client, is it to mitigate bots or should it also affect a human scrolling the map really fast? tile caching in the browser is only supported on chrome on non-windows and safari for decoding pmtiles in the browser. using go-pmtiles serve or Martin you could cache the tiles in a CDN but that isn't really rate limiting. |
Beta Was this translation helpful? Give feedback.
The issue of potentially unlimited egress fees due to bots isn't unique to PMTiles, it can happen with video files, GeoJSON files or any kind of static asset on storage. So any solution isn't specific to PMTiles either, there are hosted solutions like AWS Web Application Firewall, or you can use Cloudflare or a unmetered bandwidth server like from OVH.
If the webview framework uses MapLibre GL JS and you are using addProtocol to decide tiles on the client, it should cache according to TTL on the client if it's Safari or non-windows chrome.