Accès à wp-json forbidden (403)

FlorentB3 2018-08-17 20:21:55 UTC #1

Bonjour,
J'ai déployé plusieurs sites Wordpress sur un serveur mutualisé.
Sur tous, j'ai la même erreur dès lors où je cherche à avoir à accès /wp-json, à savoir, une erreur 403 visible dans la console de Chrome qui empêche toutes mises à jour.
C'est embêtant pour certains plugins :
- mise à jour impossible de Jetpack
- utilisation impossible de Gutemberg qui équipe pourtant WP en natif maintenant.

Quel est le problème ?

Dans Wordpress Si vous avez l'erreur "Mise à jour échouée" lors de la rédaction d'un article

FlorentB3 2018-08-18 06:57:48 UTC #3

Bah. Disons que c'est le chemin d'accès à l'API Rest de WP pour les POST et GET ajax (je crois).
Sur les sites sans Gutemberg, c'est le même souci.
@ovhweb n'aurait il bloqué l'accès à l'API lors du hackage de WP l'an dernier?

CharlieM2 2018-08-23 00:34:06 UTC #5

Même soucis sur la plupart de mes sites, les requêtes POST vers /wp-json/wp/v2/posts (et autres post types, d'ailleurs) renvoient systématiquement une erreur 403. Très ennuyeux quand on a des projets entiers basés sur l'API REST… Problème observé sur des multisites, des sites basiques, avec ou sans Gutenberg, avec ou sans JetPack, avec ou sans plugins tout court.

kyodev 2018-08-23 11:33:38 UTC #6

je viens d'essayer sur un wordpress, installation manuelle, sans plugins, sorti de la boite:

installation gutemberg, erreur 403 /wp-json/wp/v2/posts/...

même procédure sur mon nouvel hébergeur:

installation gutemberg, TOUT fonctionne

j'ai rien trouvé dans la doc api rest pour me mettre sur la voie, j'ai essayé deux plugins d'authentification, deux navigateurs, un réglage htaccess, des accès curl avec authentification, rien toujours la même erreur

Ovh pose problème (un de plus)

CharlieM2 2018-08-23 11:43:38 UTC #7

J'ai − apparemment − résolu le problème en désactivant le firewall, hint donné par cette réponse à un autre sujet. Mon serveur était déjà en production et stable, mais avec firewall activé ; http.firewall=nonea immédiatement réglé le problème de 403. À voir si ça tient dans le temps…

kyodev 2018-08-23 12:00:05 UTC #8

ah curieux, j'ai le firewall désactivé pourtant, mais oui, sur le principe, il VAUT MIEUX ne pas l'activer ici (mod_security, apache)

kyodev 2018-08-24 11:54:08 UTC #9

j'ai fait un test dernièrement sur ce "firewall".
je l'ai activé pour tester une discussion.

MAIS même désactivé, je vois qu'il est toujours en place :/

kyodev 2018-09-03 13:41:32 UTC #10

désactiver firewall récalcitrant:
https://community.ovh.com/t/admin-inaccessible/10314/6?u=kyodev

NicolasK6 2018-09-14 21:32:36 UTC #11

Salut,
Je me permet de faire remonter le fil de message pour signaler également ce même problème.
Il sera peut être intéressant de savoir en détail ce qu'il se passe si l'on désactive le firewall applicatif.

Je peux founir plus d'information sur ce qui se passe entre Gutenberg et le REst Api de wordpress.
cette erreur 403 génère le message d'erreur suivant:
ModSecurity: Access denied with code 403 (phase 2). Match of "within %{tx.allowed_request_content_type}" against "TX:0" required. [file "/usr/local/apache2/conf/modsecurity/base_rules/modsecurity_crs_30_http_policy.conf"] [line "63"] [id "960010"] [msg "Request content type is not allowed by policy"] [data "application/json"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] [hostname "mon-site.com"] [uri "/wp-json/jetpack/v4/settings"] [unique_id "W5mhcQoAXz8AAEna5LAAAAAZ"]

Je pensais whitelister l'ID 960010 avec , mais il parait qu'il n'est pas possible de le faire avec un fichier htaccess, alors l'unique solution est de desativé le firewall, mais qu'es-ce que cela implique ?
Et si le firewall est désactivé, peut-on toujours utiliser les fonctions suivantes ?
RewriteEngine, RewriteCond, RewriteRule, SetEnvIF, mod_authz_core.c, mod_rewrite.c, mod_expires.c, mod_headers.c et Options -Indexes.

le but du firewall, est surement de permettre de bannir des ips, user agent etc.., puis j'ai besoin de gérer la mise en cache et l'expiration etc...

Si quelqu'un pouvait me confirmer que la désactivation du firewall, n’empêche pas toutes ces fonctions d’être utiliser dans mon htaccess, je pourrai me satisfaire de cette situation :)
Mais dans le cas inverse le firewall ne devrait pas être désactivé et toutes ces problèmes avec Jetpack et gutenberg reviendront après la réactivation du firewall.

Nicolas

Hébergement Cloud Web et Wordpress : erreur 400

janus57 2018-09-14 21:48:48 UTC #12

Bonjour,

le firewall n'active ou ne désactive aucune fonction de apache, il fait juste du filtre sur des règles que seul OVH connait (car c'est eux qui les gèrent).

Donc si il vous pose problème ==> désactivation.

Cordialement, janus57

kyodev 2018-09-14 21:54:26 UTC #13

Il sera peut être intéressant de savoir en détail ce qu'il se passe si l'on désactive

moi j'aimerai bien savoir en détail ce qu'il se passe quand on l'active alors qu'il est désactivé par défaut

ne pas confondre un firewall avec cet affreuse appellation ici du mod_security de Apache

NicolasK6 2018-09-14 22:58:59 UTC #14

hey les réponses sont rapides ici :)
merci @janus57 et @kyodev pour la clarification, donc je vais définitivement désactivé ce foutu firewall.
Il est étonnant que si peu de personne rapporte ce problème avec le nouvel éditeur de wordpress de plus ce problème existe depuis la refonte de la page settings de Jetpack, donc c'est pas tout récent.
Ovh propose le one click install de wordpress, je sais pas si lorsqu'on commande un hébergement, si le firewall est actif par défault, peut etre que si c'était le cas, bcp plus de personne viendraient se plaindre ici. de plus Gutenberg doit être installé manuellement ce qui réduit peut être encore un peu son utilisation.
Si j'avais su j'aurai pas perdu autant de temps a vouloir tout débugger moi meme, j'ai meme été jusqu'a paramétrer un environnement de travail pour compiler la version master actuelle de gutenberg avec node JS et toutes ces dépendances, évidement ceci n'a eu aucun effet sur le problème principale ^^

En ce qui concerne le fonctionnement du firewall ovh j'ai trouvé cette article, même si les détails techniques sont minimes.Je ne sais pas si avec le recule, ce sont de simple arguments marketing, ou si réellement ce firewall permet de ce préserver des attaques ddos usuelles.

janus57 2018-09-14 23:02:14 UTC #15

Bonjour,

il n'a rien à voir avec le firewall du mutu qui est un WAF et qui se nomme mod_security.

Cordialement, janus57

kyodev 2018-09-14 23:03:10 UTC #16

par défaut ce n'est pas activé
l'article ne concerne pas le même firewall dont on parle ici
c'est un abus de langage de Ovh de parler du firewall pour le site, c'est juste un mod_security apache activé avec des règles obscures

NicolasK6 2018-09-15 00:54:19 UTC #17

mea culpa ;)
donc c'est quoi ce firewall network dans le VAC ?
il s'active également par mitigation lorsqu'une attaque ddos est détectée ?
il n'est vraiment pas évident d'avoir plus d'information sur ce firewall, je vais tenir compte de la description de janus57. et au moins je suis rassuré sur le fait que ce firewall, n'empêche pas la protection anti ddos si celui ci est désactivé. cela dit il serait louable de faire un vrai article qui détail les conséquences de ce choix.

janus57 2018-09-15 10:48:29 UTC #18

Bonjour,

c'est un firewall de "pré-filtrage" dans la solution anti-DDoS de OVH, mais c'est valable pour les VPS/Dédié, le mutu a encore une autre protection anti-DDoS plus spécifique.

Cordialement, janus57

MatthieuL11 2018-10-03 13:18:05 UTC #19

Bonjour à tous,
Même problème de base pour moi, mais fait étrange :
- l'appel à l'API dans le code renvoie une erreur 403 dans la console
- par contre en appelant l'URL en erreur directement dans le navigateur elle s'affiche sans problème. Idem si appel via CURL.
- le problème ne se produit que pour les utilisateurs non connectés
Et ça ne se produit que chez OVH, pas de soucis en local ou sur d'autres hébergements.
Le firewall est bien désactivé (depuis l'interface OVH et dans le .ovhconfig), alors je n'ai plus d'idée.
Si vous avez des pistes je suis preneur. Je vais interpeller le support à ce sujet.

VincentP15 2019-01-02 13:18:55 UTC #20

Bonjour à tous,

Meme problème que ce que tout le monde rapporte plus haut : Je viens de faire la MAJ wordpress 5.02 et depuis, plus possible d'enregistrer les articles (je suppose que c'est la passage au nouvel éditeur qui pose problème) ou encore de modifier les réglages dans Jetpack (ça il me semble que j'avais déjà le soucis avant la MAJ). Bref le seul moyen pour que tout fonctionne désormais est de désactiver le firewall OVH (dans l'onglet multisite)..
Du coup j'ai bien un plugin de sécurité, mais que risque t on à ne plus utiliser le firewall OVh, est il si performant que ça ?
Sinon quelqu'un a une idée pour contourner cela (je veux dire utiliser le Firewall OVH sans que cela ne gêne pour l'utilisation du site) ?

kyodev 2019-01-02 13:38:32 UTC #21

comme indiqué plus haut, ce truc mal configuré sur Ovh n'est pas une sécurité!

ce n'est pas la faute de mod_security en lui même

si tu veux tu veux utiliser le le Firewall OVH, change de cms ;)

DidierB19 2019-01-03 18:31:12 UTC #22

Bonjour à tous,

même problème que vous. Je ne l'avais constaté pour le moment que sur la page de réglages de Jetpack.
Mais avec l'arrivée de Gutenberg, c'est beaucoup plus problématique : on ne peut pas créer d'article.
La fonction de sauvegarde automatique ne fonctionne pas, on ne peut pas visualiser un brouillon.

A chaque requête de sauvegarde auto (http://mon_nom_de_domaine/wp-json/wp/v2/posts/3267/autosaves?_locale=user) on obtient une erreur 403.
Je trouve ça fou de devoir désactiver mod_security.
Ovh ne peut pas régler le problème ?

Propulsé par Discourse, le rendu est meilleur avec le JavaScript activé

OVHcloud Community

Bienvenue sur votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres d'OVHcloud Community.