Closed nicolas-jaussaud closed 5 months ago
Thanks for the pull request!
Because the error message is localized, WordPress will try to look for the current user local and will end-up calling _wp_get_current_user, which will trigger the determine_current_user filter and call our method again.
I see, that's a tricky bug - I appreciate you tracking down the cause and solving it. And thanks for the helpful issue description and the code comment to explain the solution. This part of the API module is adapted from a fairly well-used library, so I'm surprised no one has caught it before.
OK, I refactored the module to remove the unnecessary use of filters and localization of error messages. (https://github.com/TangibleInc/template-system/commit/e0553d2105b68df2a4e728c1dfeb2e46ab830e07) That simplifies things so there's no possibility of this issue happening.
I've pushed the Framework module to its repo with npm run subrepo push framework
. You can run composer update
to pull the newest changes.
That was fast, thank you!
Hi Eliot!
I recently noticed an issues with some endpoints that returns a 503 error on sites where the framework is used
The issue can be reproduced by creating or updating a new page on a WordPress site
The requests made on the initial page load will return a 503 error:
All those requests pass
_locale
as a GET parameter, and the issue seems to only happen when this parameter is setIn the error logs, there is the following error for each request:
From the associated stack trace it seems that there is indeed an infinite loop, caused by the
determine_current_user
filter we set inroutes.php
(here), which will trigger thedetermine_current_user
filter again (by callingvalidate_token
, here):The issue seems to come from the
WP_Error
returned here insidevalidate_token
Because the error message is localized, WordPress will try to look for the current user local and will end-up calling
_wp_get_current_user
, which will trigger thedetermine_current_user
filter and call our method againThe reason it only affect requests that pass
_locale
as a GET parameter seems to be because of this condition in determine_locale()This pull request should prevent this loop by removing our filter before calling
validate_token