Logger API: Add rate limiting

[bgrgicak]

Fixes #1123

What is this PR doing?

It adds rate limiting to the logger API.

What problem is it solving?

Increases protection from spam requests.

How is the problem addressed?

By tracking the number of requests in $_SESSION and returning early if the limit was reached.

Testing Instructions

• Checkout this branch
• Copy the logger.php file to a PHP local server or start a Docker server

cd packages/playground/website/public/
docker run -d -p 8787:80 --name playground-website -v "$PWD":/var/www/html php:8.0-apache

• Open the API endpoint link
• Reload 5 times and confirm that the error message changed to Too many requests

Known limitations
Because this is implemented using $_SESSION it can easily be worked around using curl or by removing session data.
To improve rate limiting we would need support for storing request counts by IP on the server and there is currently no storage support except for files.

[brandonpayton]

Because this is implemented using $_SESSION it can easily be worked around using curl or by removing session data.
To improve rate limiting we would need support for storing request counts by IP on the server and there is currently no storage support except for files.

Yeah... I guess we can revisit this with Systems if this is insufficient. It's more of a defense against unintentional overuse than it is against abuse. Still... very good to have.

[dmsnell]

would it be helpful to send a 429 here instead of what I presume is a 200?

also, these response() responses seem quite sparse. maybe we could help clue-in the browsers to what is happening?

header( 'Content-type: application/json', true, 429 );

Do we expect the clients to heed this response and wait to send new logs?

[bgrgicak]

This API is currently used only by one modal and it shows the same error message whenever a request fails, so it's not needed today.

If the API gets used more in the future, using the correct response code and improving errors would be good.

Do we expect the clients to heed this response and wait to send new logs?

No, users might click on the form again and if it fails, it would result in the same error.
Thinking about it now, the UX isn't great, but let's see how much it will be used before investing more time into it.