Repository navigation
Conversation
…nment The plugin read FLYWP_API_KEY as a PHP constant and nothing else. Classic WordPress writes that constant into wp-config.php, so it is always set. Bedrock has no wp-config.php: FlyWP writes the key into .env, and the constant exists only when a config file declares it with Config::define(). A repository built from upstream roots/bedrock does not declare it. On those sites the key was present and correct, and the plugin could not see it. has_key() returned false, init_plugin() stopped, and the router was never built. WordPress then dropped the unknown `fly-api` query variable and served the front page with a 200, which reads to a caller as a working site. - Read the key from getenv(), $_ENV and $_SERVER when the constant is empty. The loaders disagree on which they populate: bedrock-starter fills the first two, a repository using createImmutable fills neither. - Unslash the $_SERVER value. wp_magic_quotes() escapes that superglobal before any plugin loads, so a key holding a quote or a backslash would never match the bearer token, which Api::get_bearer_token() unslashes. - Load the router and the API above the key gate, so an unkeyed site answers with JSON instead of the theme. This exposes no new route: ping was already unauthenticated, and every other route stays behind the bearer check. - Report has_key in the ping body. Now that the route is registered whether or not a key was found, a 200 alone no longer means the integration works. - Stand down when this plugin is already loaded from another directory, so two copies cannot declare the same class twice. The resolver is a separate class with no WordPress functions in it, so the behaviour is covered by the existing unit suite rather than left untested. Refs flywp/flywp-app#2481, flywp/flywp-client-issues#8
Contributor
Author
|
Closed by a team decision.
The branch stays. Re-open this if the decision changes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is wrong
wp-config.php. FlyWP writes the key into the.envfile..envvalue becomes a constant only when a config file declares it.roots/bedrockdoes not declare it.What the customer sees
/fly-api/*answers with the site home page and a success code.What this changes
getenv(),$_ENVand$_SERVER, because the loaders disagree on which they fill.$_SERVER. Without this a key that holds a quote or a backslash could never match./fly-api/*with JSON. It no longer answers with the theme.pinganswer says whether the plugin found a key.Decisions worth knowing
pinganswer changed on purpose. The route is now registered whether or not a key was found. A success code alone therefore no longer proves the integration works. Read thehas_keyfield.hash_equals(). Sanitizing could change the value and break authentication.Tests
Order