Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

feat: connect Faust.js to WordPress with an Application Password

Abierto
#2,678 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@josephfusco ya está trabajando en esto.

Desde el 20/10/2026.

  • #2676 de @josephfusco — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript, wordpress

Línea de trabajo

Start by tracing how FAUST_SECRET_KEY authenticates token exchange, blockset uploads, schema introspection, health checks, and telemetry in Faust.js core and the CLI; the issue does not name specific files or tests. Then check how WordPress Application Passwords expose authenticated users and capabilities. Done means these requests can use Application Passwords with the stated capability checks while the existing secret key continues to work and encrypt tokens.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

[Area] CLI [Area] Core [Area] WordPress Plugin [Type] Feature

Every request from a Faust.js server or the CLI to WordPress authenticates with the shared FAUST_SECRET_KEY: the token exchange, faust blockset, schema introspection for faust generatePossibleTypes, the CLI's health checks and telemetry. One value does all of these, so a credential that only needs to exchange tokens can also upload blocksets, and rotating it logs every user out because the plugin also uses it to encrypt tokens.

Proposal

Let core and the CLI authenticate with a WordPress Application Password instead, checked against capabilities:

  • faustwp_exchange_tokens for the token exchange, health checks and telemetry. Administrators have it, and it can be added to a custom role for a dedicated user.
  • faustwp_upload_blocks for blockset uploads, limited to users who can manage the site's options (the network's on Multisite).
  • Schema introspection works for any authenticated Application Password, since WPGraphQL already allows it.

FAUST_SECRET_KEY keeps working and keeps encrypting tokens, so this is additive. Whether and when to deprecate the secret key is a separate decision.

Trade-offs

  • WordPress only accepts Application Passwords over HTTPS or on local environments.
  • Some servers strip the Authorization header, and sites protected with HTTP Basic auth can't use Application Passwords, since both use that header (see #1850, #1524, #851).

Related

  • #2673 documents Application Passwords for server-side writes, replacing the service-key idea in #2561.
  • #2564 and #1512: authentication outside Next.js relies on existing tools rather than a Faust package.
  • #2310 / #2312: how the secret key is compared today.
Lenguaje dominante
TypeScript
Estrellas
1.6k
Forks
157
Merge medio
1 d 5 h
PR fusionados (30 d)
121

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de wpengine/faustjs

Todos los issues de wpengine/faustjs

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.