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

Refreshing client-credentials BYOIDC

Abierto
  • ¿Algo no está bien?
#149 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
authentication, backend-api-design

Línea de trabajo

Comienza en el punto de entrada connect() y en el punto de unión child 1 flink_auth; después compara el ClientCredentialsTokenProvider, OAuthCredentialsProvider y OAuthTokenAuthenticator referenciados en #399. Define la clase de autenticación y el cableado de connect() en torno a los parámetros external* indicados, y añade pruebas que cubran la actualización tras la expiración, el comportamiento single-flight, un único reintento ante 401 y la exclusividad de la configuración.

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

Descripción

  • Goal: reach parity with Flink Table API client PR-399's second OAuth mode — a self-refreshing external token sourced from the caller's IdP via client-credentials, so BYOIDC can sustain long-running streaming that outlives a single short-lived token (the gap child 1 documents but does not solve).
  • Surface: new connect() params mirroring the plugin's option names — external_token_url, external_client_id, external_client_secret, external_token_scope. Mutually exclusive with the static external_access_token and with every API-key param. - Scope (in): a refreshing httpx.Auth for the _flink_auth slot built around an internal token-source member — a callable yielding a token and its expiry — that the refresh machinery (single-flight caching, proactive refresh ahead of expiry, forced re-fetch + one retry on HTTP 401) wraps uniformly. Child 2 ships the canned implementation of that source: an OAuth2 client-credentials grant against external_token_url (the driver reads expires_in off the grant response, which is what feeds proactive refresh). The #138 401→OperationalError translation is the fallback if refresh can't recover.
  • Out of scope: any control-plane reach (still Flink-only); the Auth0 chain and everything in the sibling interactive epic.
  • Depends on: child 1's _flink_auth seam.
  • Reference: #399 internal/ClientCredentialsTokenProvider (the canned client-credentials
    source) wrapped by OAuthCredentialsProvider (single-flight, 30s skew) + OAuthTokenAuthenticator
    (MAX_ATTEMPTS=2, 401-driven refresh).
  • Sized right: one new auth class + connect() wiring + tests; no new package, no threads
    beyond the refresh single-flight, no control-plane surface.

Near-free follow-on (2b) — caller-supplied token source. Because child 2 is built around the > internal token-source member above, exposing a caller-supplied implementation is a widening, not > a separate mechanism: the auth keeps the source as a data member and either instantiates its canned > client-credentials impl (given the config params) or defers to a callable the caller passes — the > refresh machinery is identical either way. This is exactly #399's factoring > (OAuthCredentialsProvider wraps some OAuthTokenProvider; ClientCredentialsTokenProvider is > the built-in one, a registered callback is the BYO one), and it covers non-standard sources — Azure > Managed Identity, AWS IAM workload identity, in-house token services. The one added contract: > for the BYO callable to get the same proactive refresh as the canned source it must surface a > token plus an expiry (#399's OAuthToken(accessToken, expiresAt)), not a bare str — a bare > string can only be refreshed reactively on 401. File it only when a concrete non-standard-source > demand surfaces; the seam it needs already exists from child 2.

Lenguaje dominante
Python
Estrellas
6
Forks
1
Merge medio
1 d 2 h
PR fusionados (30 d)
15

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 confluentinc/confluent-sql

Todos los issues de confluentinc/confluent-sql

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.