microcks / microcks/microcks-cli

Persisted context TLS settings are inconsistent for different HTTPS servers

Abierto
#286 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
Go
Estrellas
52
Forks
68
Merge medio
6 h 54 min
PR fusionados (30 d)
10

Descripción

Describe the bug

The CLI stores TLS settings in the local server context, but the current behavior is inconsistent:

  1. microcks login always persists insecureTLS: true, even when the user did not pass --insecure-tls.
  2. Later commands that load the saved context do not honor the persisted insecureTLS value when building the HTTP client.

This makes saved HTTPS contexts misleading. A context can contain insecureTLS: true, but commands such as import, import-url, import-dir, and test still fail unless --insecure-tls is repeated.

This affects Microcks instances exposed over HTTPS with self-signed certificates, private CA certificates, local ingress TLS, or internal reverse proxies.

Common examples:

  • Microcks behind local k3s / ingress TLS
  • Microcks behind Caddy, nginx, Traefik, or an internal gateway
  • Instances using private PKI
Expected behavior

If the user logs in with --insecure-tls, later commands using that saved context should honor the persisted TLS setting.

If the user logs in without --insecure-tls, the saved context should not be marked insecure.

Actual behavior

No response

How to Reproduce?

Given a Microcks server available at an HTTPS endpoint with a self-signed or private certificate:

microcks login https://microcks.example.local --insecure-tls

This succeeds and stores:

server: https://microcks.example.local
insecureTLS: true

But a later command using the saved context can fail:

microcks import openapi.yaml

with an error like:

tls: failed to verify certificate: x509: certificate signed by unknown authority

Repeating the flag makes the same command work:

microcks import openapi.yaml --insecure-tls

Guía de contribución

Abrir la guía de contribución

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.

Línea de trabajo

Comienza siguiendo cómo el comando login persiste el contexto del servidor local y cómo import, import-url, import-dir y test construyen sus clientes HTTP. Verifica ambas rutas de login y la carga del contexto guardado: --insecure-tls debería persistirse y respetarse posteriormente, mientras que un login sin esta opción no debería marcar el contexto como inseguro.

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

Evaluación

Stack tecnológico
go
Área
cli
Tipo de issue
Error
Dificultad
3/5
Tiempo estimado
1-2 días
Estado de actividad
Tranquilo
Claridad
Bastante claro
Aptitud para principiantes
68/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.