Constantes PHP et Variables d'Environnement via Schema
Récupère la valeur d'une variable d'environnement ou d'une constante PHP.
Description
Cette extension ajoute le champ global _env au schéma GraphQL, qui permet d'obtenir une valeur depuis une variable d'environnement, ou depuis une constante PHP (le plus souvent définie dans wp-config.php, mais pouvant aussi être définie ailleurs).
Pour des raisons de sécurité, le nom de la variable d'environnement et des constantes accessibles doit être configuré explicitement.
Le champ _env reçoit le nom de la variable d'environnement ou de la constante sous le paramètre "name", et est résolu comme suit :
- S'il existe une variable d'environnement portant ce nom, elle est retournée
- Sinon, s'il existe une constante portant ce nom, elle est retournée
- Sinon,
nullest retourné et une erreur est ajoutée à la sortie GraphQL.
Par exemple, cette requête récupère la constante d'environnement GITHUB_ACCESS_TOKEN que nous pourrions configurer pour accéder à un dépôt privé sur GitHub :
{
githubAccessToken: _env(name: "GITHUB_ACCESS_TOKEN")
}Cette requête récupère la configuration de la BD définie dans le fichier wp-config.php :
{
dbName: _env(name: "DB_NAME")
dbUser: _env(name: "DB_USER")
dbPassword: _env(name: "DB_PASSWORD")
dbHost: _env(name: "DB_HOST")
}Configurer l'accès aux constantes d'environnement
Nous devons configurer la liste des variables d'environnement et des constantes autorisées qui peuvent être interrogées.
Chaque entrée peut être :
- Une regex (expression régulière), si elle est entourée de
/ou#, ou - Le nom complet de la variable ou de la constante, sinon
Par exemple, chacune de ces entrées correspond à la variable d'environnement "GITHUB_ACCESS_TOKEN" :
GITHUB_ACCESS_TOKEN#^([A-Z]*)_ACCESS_TOKEN$#/GITHUB_(\S+)/
Il y a 2 endroits où cette configuration peut être effectuée, par ordre de priorité :
- Personnalisée : Dans la Schema Configuration correspondante
- Générale : Dans la page des Réglages
Dans la Schema Configuration appliquée à l'endpoint, sélectionnez l'option "Use custom configuration" puis saisissez les entrées souhaitées :

Sinon, les entrées définies dans l'onglet "Environment Fields" des Réglages seront utilisées :

Il y a 2 comportements, "Allow access" et "Deny access" :
- Allow access : seules les entrées configurées peuvent être accédées, aucune autre ne le peut
- Deny access : les entrées configurées ne peuvent pas être accédées, toutes les autres entrées le peuvent

Sécurité : Accès aux variables d'environnement
L'extension applique plusieurs couches de protection pour éviter l'exposition de données sensibles :
-
Les utilisateurs doivent être connectés pour accéder à ces champs.
-
La liste des variables d'environnement pouvant être interrogées est vide par défaut, donc aucune entrée n'est lisible jusqu'à ce qu'elle soit explicitement configurée.
-
Les utilisateurs admin ont accès à toutes les variables d'environnement.
-
Pour les utilisateurs non-admin, les variables d'environnement suivantes se voient toujours refuser l'accès — même lorsqu'elles sont explicitement autorisées dans la configuration :
Variables d'environnement WordPress :
AUTH_KEYSECURE_AUTH_KEYLOGGED_IN_KEYNONCE_KEYAUTH_SALTSECURE_AUTH_SALTLOGGED_IN_SALTNONCE_SALTDB_NAMEDB_USERDB_PASSWORDDB_HOSTDB_CHARSETDB_COLLATE
Variables d'environnement contenant l'un de ces sous-strings dans leur nom :
PASSWORDPASSWDSECRETPRIVATE_KEYAPI_KEYAPIKEYACCESS_KEYACCESS_TOKENAUTH_TOKENBEARERCREDENTIALSALT
Sécurité : Ne pas exposer les identifiants
Sauf si notre API GraphQL n'est pas exposée publiquement (comme lors de la construction d'un site statique), nous devons veiller à ce que la requête GraphQL n'expose pas de données privées :
- Dans la réponse de la requête
- Dans la sortie lorsqu'une erreur se produit
- Dans les logs
Par exemple, la requête suivante :
{
githubAccessToken: _env(name: "GITHUB_ACCESS_TOKEN")
}...affichera directement les identifiants dans la réponse :
{
"data": {
"githubAccessToken": "{some access token}"
}
}Nous pouvons utiliser plusieurs des autres fonctionnalités du plugin pour sécuriser la requête GraphQL :
- Field to Input pour injecter la valeur d'environnement dans un autre champ via une variable dynamique
- Field Response Removal pour éviter d'afficher la valeur de la variable d'environnement dans la sortie
- HTTP Client pour se connecter directement à un service externe depuis l'intérieur de la requête GraphQL
Par exemple, la requête suivante se connecte à l'API REST de GitHub en utilisant un token d'accès privé :
{
githubAccessToken: _env(name: "GITHUB_ACCESS_TOKEN")
# This directive will remove this entry from the output
@remove
# Create the authorization header to send to GitHub
authorizationHeader: _sprintf(
string: "Bearer %s",
# "Field to Input" feature to access value from the field above
values: [$__githubAccessToken]
)
# Do not print in output
@remove
# Use the field from "Send HTTP Request Fields" to connect to GitHub
gitHubArtifactData: _sendJSONObjectCollectionHTTPRequest(
input: {
url: "https://api.github.com/repos/GatoGraphQL/GatoGraphQL/actions/artifacts",
options: {
headers: [
{
name: "Accept"
value: "application/vnd.github+json"
},
{
name: "Authorization"
# "Field to Input" feature to access value from the field above
value: $__authorizationHeader
},
]
}
}
)
}Dans cette requête, les champs githubAccessToken et authorizationHeader (qui contiennent des données sensibles) sont tous deux supprimés de la sortie, et le champ gitHubArtifactData affichera déjà les résultats de l'appel API, sans exposer aucune de ses entrées (par exemple : une erreur affichera la chaîne "$__authorizationHeader" plutôt que la valeur de la variable).