microcks / microcks/microcks-cli
Persisted context TLS settings are inconsistent for different HTTPS servers
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 52
- Forks
- 68
- Avg merge
- 6h 54m
- Merged PRs (30d)
- 10
Description
### 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:
```sh
microcks login https://microcks.example.local --insecure-tls
```
This succeeds and stores:
```yaml
server: https://microcks.example.local
insecureTLS: true
```
But a later command using the saved context can fail:
```sh
microcks import openapi.yaml
```
with an error like:
```text
tls: failed to verify certificate: x509: certificate signed by unknown authority
```
Repeating the flag makes the same command work:
```sh
microcks import openapi.yaml --insecure-tls
```
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how the `login` command persists the local server context and how `import`, `import-url`, `import-dir`, and `test` build their HTTP clients. Verify both login paths and saved-context loading: `--insecure-tls` should persist and be honored later, while login without it should not mark the context insecure.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100