it turns out that the server implementation relies on the clients doing
the whole auth flow over the same connection, but `go` will only let you
reuse a given tcp connection if you've completely drained the response's
body (which `--verbose` ends up doing, despite copying everythign back
to a new reader).
Signed-off-by: Ciro S. Costa <utxobr@protonmail.com>
example:
monerod --rpc-login foo:foo (...)
monero daemon -u foo -p foo get-version
new flags
-p, --password string password to supply for rpc auth
-u, --username string name of the user to use during rpc auth
Signed-off-by: Ciro S. Costa <utxobr@protonmail.com>
well, `pkg/rpc` in theory already supported tls given that it relies on
an `http.Client` which could already be making use of such proxy, but at
least now we make it configurable to the CLI in a nice way
very command under `monero daemon|wallet` now takes:
Flags:
-a, --address string full address of the monero node to reach out to (default "http://localhost:18081")
-h, --help help for daemon
--request-timeout duration how long to wait until considering the request a failure (default 1m0s)
--tls-ca-cert string certificate authority to load
--tls-client-cert string tls client certificate to use when connecting
--tls-client-key string tls client key to use when connecting
-k, --tls-skip-verify skip verification of certificate chain and host name
-v, --verbose dump http requests and responses to stderr
Signed-off-by: Ciro S. Costa <utxobr@protonmail.com>
- using `cobra` for sake of better organization when it comes to command
hierarchy
- splitting `rpc` into `daemon` and `wallet` so we can start thinking of
monero-wallet-rpc support
Signed-off-by: Ciro S. Costa <utxobr@protonmail.com>
- there's no reason why we should be exporting those method names, so
let's unexport them
- with a common factory for creating a deadlined context and client, we
have to care less about those details inside the commands themselves
Signed-off-by: Ciro S. Costa <utxobr@protonmail.com>
DataHoarder
