A discussion on a recurring issue where users receive a 429 Too Many Requests error when loading emojis in the post editor. Fredo initially reports the issue, suggesting it may be due to Discourse considering multiple requests to load emojis as a potential DDOS attack.
SAM points out that combining emojis into a sprite would be unnecessary with HTTP/2 and asks for clarification on whether the issue occurs on meta.discourse.org or another hosted site. Codinghorror also requests clarification, which Fredo provides, stating the issue occurs on a hosted site (https://forums.sketchup.com/) and can be reproduced by quickly scrolling through emojis.
SAM assigns the issue to himself and proposes two solutions: whitelisting emoji requests from the CDN and centralizing emoji storage across sites. Codinghorror also suggests centralizing avatar paths. SAM later updates that while some improvements have been made, centralizing emoji storage remains a significant task that has not been scheduled.
Canapin ultimately considers the issue fixed due to a lack of recent occurrences.
After opening the emoji selector in the post editor, discourse throws users out once they load a page again (like after submitting a post).
429 Too Many Requests
Your IP address has made too many requests to this service over a short amount of time. Please wait a few minutes and try again.
If you are behind a proxy or coming from a large company, you and many other users may appear to be the same person. Please let us know of recurring problems by email: team@discourse.org
It seems it was not the user trying to DDOS discourse, but discourse itself. If there is a way, maybe distinct requests to resources (like emojis) should not be considered? Or all emojis should be combined into a sprite?
Hemos hecho mucho aquí para mejorar la situación: reglas más estrictas en nuestro CDN y límites más flexibles para los emojis.
El cambio fundamental de que todo nuestro alojamiento utilice una única ubicación para todos los emojis aún no se ha realizado, y no podemos ver cómo programarlo en un futuro cercano debido a la magnitud de tal cambio.