500 errors after updating to 9.0.33

Hi @remyjacobs,

Thank you for getting in touch, we do appreciate your time. I am sorry to hear that you are still seeing log reports with 500 errors. I suspect this is due the rejection taking place as a result of an exception being thrown (missing marker ID).

Could I ask you to share a small subset of your latest logs with me? Then I should be able to log this for further adjustment on our side.

We still believe those logs to be a result of the pen-testing which is happening on some sites by some external party. Although the codebase has been fixed to prevent that issue from causing larger problems, it’s more difficult to prevent them all together due to the endpoints being public.

With that said, with the new/updated logs, we might be able to take further action. I look forward to hearing back from you.

Hi Dylan,

Thanks for your reponse. I guess you’re right. Here are some examples;

thehagueboat.com [08/Mar/2024:00:28:28 +0000] GET "/wp-json/wpgmzA/v1/markers?_method=get&random=/wpgmza/v1/markers/1" HTTP/2.0 500 "https://thehagueboat.com/wp-json/wpgmzA/v1/markers?_method=get&random=/wpgmza/v1/markers/1" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3" "/index.php" - - 444 0.325 0.325
thehagueboat.com [08/Mar/2024:00:28:30 +0000] GET "/wp-json/wpgmzA/v1/markers?_method=get&random=/wpgmza/v1/markers/2" HTTP/2.0 500 "https://thehagueboat.com/wp-json/wpgmzA/v1/markers?_method=get&random=/wpgmza/v1/markers/2" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3" "/index.php" - - 444 0.181 0.180
thehagueboat.com [08/Mar/2024:00:28:30 +0000] GET "/wp-json/wpgmzA/v1/markers?_method=get&random=/wpgmza/v1/markers/3" HTTP/2.0 500 "https://thehagueboat.com/wp-json/wpgmzA/v1/markers?_method=get&random=/wpgmza/v1/markers/3" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3" "/index.php" - - 444 0.179 0.179

Hi there,

Thank you very much for sending those over, yes that confirms my thoughts on the issue. It seems someone is testing the endpoint.

The plugin is rejecting that as expected, and you can validate that by going to the first request in your example. You should see a message stating that the marker was not found.

What we have established is that because the return is a generic error, the REST API is returning a 500 status code. Although this isn’t intrinsically wrong, what we should be doing is returning a 404 status code.

That would prevent any error monitoring on your host side from reporting the issue to you. I’ve already logged that on our roadmap, and you can expect to see that change in the next update.

That’s good to hear. Any idea when to expect the next update?

Hi @remyjacobs,

We don’t have a release date yet, with the last release being quite recent. However, tentatively it should be within the next week or two at most as we have some other items in progress.

With that said, if you’d like a short term solution, you’re welcome to open a support ticket on our website, and I’d be happy to discuss some options with you.

Hi @remyjacobs,

Just a quick update to let you know that an update has just been released to change the response code to a standard 404 error code, which should not flag any automatic monitoring.

After the new update all the errors are gone. Thanks for the quick response!

Fantastic, thank you for confirming!