Critical. Openstreetmap has blocked access to the map component

Bug reports
1

The problem is not related to a local installation but is affecting the Map component itself.

image
image2406×1486 357 KB

The blocking message suggests this impacts all solutions, and points to Tile Usage Policy

As a workaround, you can uncheck “Use default map” and instead use a Map layer with a function that returns:

https://{s}.basemaps.cartocdn.com/light_all/{z}/{x}/{y}{r}.png

Don’t forget the attribution: Tiles: © CARTO / Map data: © OpenStreetMap contributors

image
image1218×321 15 KB

Remember to add https://*.cartocdn.com to image sources.

There are other free map tile URLs available if needed.

2

Hi,

The Map Component looks fine on my end. I have tried with the one in Showroom and also a new Map Component.

image
image1920×928 157 KB

The requests for tiles is sent from your client, not our backend; could it be that you are blocked from Open Street Maps?

OSM’s usage policy states that:

  • Valid HTTP User-Agent identifying application. Faking another app’s User-Agent WILL get you blocked. Using a library’s default User-Agent is NOT recommended as they may be blocked if another user of the library is misusing it. If a device automatically sends an X-Requested-With header with an application specific Application ID, this will be considered an acceptable substitute for the HTTP User-Agent, although we still recommend setting a valid HTTP User-Agent for the application.

  • When coming from a web page, a valid HTTP Referer. Apps generally do not have a HTTP referer.

  • DO NOT send no-cache headers. (“Cache-Control: no-cache”, “Pragma: no-cache” etc.)

  • Cache Tile downloads locally according to HTTP Expiry Header, alternatively a minimum of 7 days.

  • Recommended: HTTP/2 or HTTP/3 support to allow multiplexed downloads

Note: modern web browsers in standard configuration pass all the above technical requirements.

Tile Usage Policy

Does your browser correctly send the required headers to Open Street Maps?

// Erik

3

I can confirm that things are back to normal on my side as well. I noticed the problem around 23:00 CET yesterday when I had planned a deployment. It was still present two hours later, when I had updated all my map URLs to point to alternative servers. I tested on Vivaldi, Chrome, Chromium and visiting my site on mobile (Vivaldi and built-in browser) via VPN from various countries. I have no idea what caused the issue.
Did nobody else notice?

4

A member of our Dev Team noticed on the OSM Slack that they had issues with the same error. They fixed it by removing the refer-check at around 02:00. It might seem like OSM rolled out some changes that did not work as expected.

image
image480×310 63.9 KB

// Erik

1 Like
5

This thankfully confirms that I’m not losing my mind — not yet, anyway.