microcks / microcks/microcks-cli
Persisted context TLS settings are inconsistent for different HTTPS servers
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:
microcks loginalways persistsinsecureTLS: true, even when the user did not pass--insecure-tls.- Later commands that load the saved context do not honor the persisted
insecureTLSvalue 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
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- 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