L’API REST de WordPress retorna 401 Unauthorized: galetes, nonces i contrasenyes d’aplicació

Què importa primer: La ruta REST existeix, però WordPress o una capa d’autenticació no accepta les credencials subministrades. El navegador galetes, REST nonces, contrasenyes d’aplicació i tokens al portador fallen per diferents raons.

Què indica realment aquest símptoma

Un 401 és útil perquè redueix l’incident a identitat i autorització. El codi de resposta, capçalera WWW- Authenticate i context d’usuari mostren si la petició mai es va autenticar o autenticar sense la capacitat requerida.

Recull proves abans de canviar res

• Truqueu al mateix punt final sense credencials i amb el mètode de credencial previst.
• Escriu el cos de la resposta i la capçalera de la WWW-Authenticate.
• Confirma que el compte d’usuari està actiu i té la capacitat requerida per la ruta.
• Comprova si un intermediari o una regla de seguretat elimina les capçaleres d’autorització.

Causes més habituals

• Falta REST nonce: Les sol· licituds del navegador autenticades amb galetes neceswebn un wp _ rest nonce actual.
• Capçalera d’autorització ratllat: Apache, Nginx, un intermediari o CDN no poden passar credencials bàsiques o portadores a PHP.
• Contrasenya de l’aplicació revocada: La contrasenya pot haver estat eliminada, trencada o lligada a un usuari diferent.
• Desajustament de la capacitat: l’autenticació té èxit, però la devolució de permisos de l’endpoint nega a l’usuari.

Seqüència segura de diagnòstic i reparació

1. Escolliu un mètode d’autenticació i prou- lo fora de l’aplicació amb una petició mínima.
2. Passeu la capçalera Autorització a través de cada capa d’intermediari i servidor web.
3. Genera una nova contrasenya d’aplicació només per a l’usuari requerit i la integració.
4. Verifica la devolució de permisos de l’endpoint contra el rol previst en comptes de concedir un ampli accés a l’administració.

Com distingir entre les causes probables

No tractis Falta REST nonce i Capçalera d’autorització ratllat com a causes equivalents. Les sol· licituds de navegador autenticades amb galetes neceswebn un wp_ rest nonce actual. En canvi, apache, Nginx, un intermediari o CDN no poden passar credencials bàsiques o portadores a PHP. Per distingir- les, useu aquestes dues comprovacions: Truqueu al mateix punt final sense credencials i amb el mètode de credencial previst; i grava el cos de la resposta i la capçalera de la WWW-Auttenticate. Amb aquestes dades podràs decidir si convé aplicar la primera acció controlada —Elisa un mètode d’autenticació i prébel fora de l’aplicació amb una petició mínima— o si has de conservar l’estat actual i ampliar la investigació.

En un lloc de WordPress en producció, repeteix la petició que falla mentre comprova una pàgina que funciona correctament i l’àrea d’administració. Un error aïllat en una ruta requereix un rollback més acotat que un problema que afecta PHP, la base de dades o totes les peticions. Documenta la data i hora exactes, la URL o transacció afectada, l’últim estat correcte conegut i cada canvi realitzat durant el diagnòstic. Aquest registre permet distingir una reparació reproduïble d’una desaparició temporal del símptoma.

Què no has de fer

Mai exposis una contrasenya WordPress en URLs, registres o JavaScript. Usa contrasenyes d’aplicació o un token dissenyat específicament i rota’ l després de provar.

Com verificar la reparació

• La integració autentica amb la credencial no interactiva prevista.
• El mateix usuari només pot accedir a les rutes i mètodes que necessita.
• Les capçaleres d’autorització i els secrets no apareixen en públic registres o font de pàgina.

Que el símptoma visible desaparegui no és suficient. Tanca la incidència només quan l’acció original que fallava, el recorregut de negoci relacionat i els registres rellevants confirmin que el problema ha desaparegut.