expand write_password option to write_sensitive in `uri.format`
Nobody has claimed this yet.
- Dominant language
- CSS
- Stars
- 15
- Forks
- 49
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 3
Description
Now write_password option is renamed to write_sensitive and expanded
to check the presence of sensitive ssl data in uri params. Next values
will be removed from returned uri if the value of write_sensitive is
set to false: password and all params which contain "ssl_" prefix.
The default value of write_sensitive is set to false.
Example:
tarantool> require("uri").format({ login = "user", password = "P4ssw0rd", host = "localhost", service = "3301" })
---
- user@localhost:3301
...
tarantool> require("uri").format({ login = "user", password = "P4ssw0rd", host = "localhost", service = "3301" }, true)
---
- user:P4ssw0rd@localhost:3301
...
tarantool> require("uri").format({ host = "localhost", service = "3301", params = { transport = "ssl", ssl_password = "P4ssw0rd", ssl_key_file = "KEY_FILE", ssl_cert_file = "CERT_FILE", ssl_ca_file = "CA_FILE" } })
---
- localhost:3301?transport=ssl
...
tarantool> require("uri").format({ host = "localhost", service = "3301", params = { transport = "ssl", ssl_password = "P4ssw0rd", ssl_key_file = "KEY_FILE", ssl_cert_file = "CERT_FILE", ssl_ca_file = "CA_FILE" } }, true)
---
- localhost:3301?ssl_cert_file=CERT_FILE&ssl_password=P4ssw0rd&transport=ssl&ssl_key_file=KEY_FILE&ssl_ca_file=CA_FILE
...
Requested by @mrForza in https://github.com/tarantool/tarantool/commit/9d60a1931cc544b7b9b8c287a56f2facf9722fe9.
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
Search the documentation for uri.format and the existing write_password option. Update the option name, default behavior, and examples to cover password and ssl_ parameters, then verify the documented output matches the examples in the issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- lua
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100