Official forums for BZFlag.org

The response from https://my.bzflag.org/db/ does not allow the contents to be retrieved from a website, as the browser will block it due to Cross-Site concerns.

Adding ["Access-Control-Allow-Origin" : "*"] to the response header would allow the content to be absorbed by by other websites for display.

In my case, I was going to present the list of servers in a filterable way, so that the user can select which servers they want to keep track of on Discord (via a bot).

I can get around it by getting my back-end to retrieve it on my behalf, so not a blocker.

Just wondering if this was an intentional oversight, and if not, any chance this will change soon?

I have noticed this too and also had to use my backend as a work-a-round. It would be very useful if you could just make the request from the browser.

The site is not intended to be consumed directly by browsers. I'm not familiar enough with the edge cases and security implications of that header given that we do use my.bzflag.org for authentication purposes.

The header has no effect on the security of bzflag.org
It has more to do with protecting browsers on the internet. Essentially, in order to stop rogue scripts from hijacking your browser and sending calls out for DDOS attacks or whatever, browsers prevent any calls outside the current domain, unless specified that it is OK by the browser, and that the other domain is OK for that particular URL to be accessed from outside of its domain.
The https://my.bzflag.org/db/ URL can be accessed by many methods, without a problem, except when you try to do it from a browser that is pointing to a different URL at the time.
The browser intercepts requests that are being made, and will prevent the call happening unless the client has not said it's OK for the browser to make the such request and the producer of the resource says that it doesn't mind being accessed from another domain.
By placing ["Access-Control-Allow-Origin" : "*"] in the header response for this call, essentially you are saying "Any domain can make the request".

There's a good description of it here

There are always ways around it, provided you have the wherewithal to tackle the extra effort, but from the rules regarding the use of this list, it seems that it was intended to be shared in this way, so it's a shame that jumping through a few extra hoops is required.

I might be totally wrong here, but perhaps it is related to "not directly forwarding login requests" which was added some time ago.
However if it is non-login related, I certainly would like to be able to get the list from the browser more easily.

-Zehra

I don't have the energy at the moment to investigate this, and I'm not going to blindly enable such a feature. This is something you can easily pull from your backend, optionally caching it in your backend.

The list is sorted by activity, which is likely to change, so caching is probably not going to be done. Besides, in my case, I need my back-end to remain stateless, so that it's easily replicated for High Availability, fail-over etc., as it's a college project, and so the implementation has specific constraints.

You're right though. The list is not designed currently to be consumed by other web-services, and there is no commitment to a particular API, so your implementation is currently allowed to change, and break any services depending on it.