Las Application Passwords no aparecen en el perfil de usuario de WordPress
El sitio no se sirve realmente por HTTPS en la URL utilizada por el asistente.
Registre las versiones de WordPress, plugin, cliente, conector y servidor antes de cambiar nada.
Causas probables
- El sitio no se sirve realmente por HTTPS en la URL utilizada por el asistente.
- El navegador usa HTTPS, pero WordPress no detecta como segura la solicitud recibida en el origen.
- Un plugin de seguridad, un plugin obligatorio o un filtro personalizado desactiva globalmente las Application Passwords.
- Las Application Passwords no están disponibles para el usuario de WordPress elegido por la integración.
- La credencial está asociada a un usuario de WordPress distinto del que espera el cliente.
Secuencia de diagnóstico
- Registre las versiones de WordPress, plugin, cliente, conector y servidor antes de cambiar nada.
- Confirme que la URL exacta usada por el asistente carga con una conexión HTTPS válida.
- Compruebe si las Application Passwords están disponibles globalmente en el entorno activo.
- Compruebe si están disponibles para el usuario exacto de WordPress.
- Revise todos los usuarios plausibles en lugar de suponer que el administrador actual posee la credencial.
- Revise la sección de Application Passwords del perfil relevante sin exponer ningún secreto.
Aplicar la corrección mínima
- Sirva las URL exactas de WordPress y REST por HTTPS antes de activar autenticación con Application Password.
- Corrija el manejo del proxy de confianza y del origen para que WordPress reconozca la solicitud HTTPS original.
- Elimine o limite el filtro que desactiva Application Passwords solo después de confirmar la política de seguridad prevista.
- Permita Application Passwords únicamente al usuario dedicado que necesita la integración.
- Cree una identidad dedicada de WordPress en vez de reutilizar al administrador humano.
Verificar el resultado
- Cada credencial observada tiene propietario, finalidad, creador, estado y decisión de revocación.
- La solicitud autenticada corresponde al usuario dedicado previsto.
- El índice REST responde desde la URL HTTPS canónica y expone los espacios de nombres esperados.
- El registro final contiene versiones, evidencia, cambio, verificación y reversión sin secretos.
Qué no hacer
- No conceda acceso de administrador solo para que una prueba de conexión funcione.
- No incluya una Application Password, encabezado Authorization, token o cookie en prompts, tickets, registros o capturas.
- No edite el núcleo de WordPress o archivos de plugins de terceros como primer paso.
- No añada una solución permanente y no verificada del proxy antes de confirmar la ruta de confianza.
- No elimine todas las credenciales desconocidas antes de registrar propietario, finalidad y último uso.
Guías relacionadas
- Las Application Passwords de WordPress están desactivadas: causas y comprobaciones
- Contraseñas de aplicación de WordPress para conexiones de IA
- Cómo encontrar las Application Passwords de WAP en WordPress
- Cómo identificar qué usuario de WordPress utiliza un asistente de IA
- WordPress no detecta HTTPS detrás de Cloudflare o de un proxy inverso
Fuentes y verificación
Esta página se verificó a partir de las siguientes fuentes primarias. Última revisión de las fuentes: .
- Application Passwords · WordPress Developer Resources
- wp_is_application_passwords_available() · WordPress Developer Resources
- wp_is_application_passwords_available_for_user() · WordPress Developer Resources
- Application Passwords REST API Reference · WordPress Developer Resources