search

Ramilito / kubectl.nvim

⎈ Streamline your Kubernetes management within Neovim—control and monitor your cluster seamlessly, all without leaving your coding environment.
Apache License 2.0
316 stars 9 forks source link

Base64 decode secrets #144

Closed RobinCamarasa closed 2 months ago

RobinCamarasa commented 2 months ago

First of all thank you for the amazing plugin!

Is your feature request related to a problem? Please describe.

I'm always frustrated when I describe a secret (using gd) and can't access the content. image

Describe the solution you'd like I would like that there is a mapping to display the secret and base64 --decode it.

Describe alternatives you've considered This adds a dependency on base64 but already having the base64 encoded secret would also help a lot.

Additional context /

Ramilito commented 2 months ago

Thank you for the suggestion! Found a lua decoder code so we managed to avoid the base64 dependency, and it seems to be working great on all the secrets I have!

What I did was to change the describe to a get -o yaml to get the encoded printed in our describe so it's visible now and not just a count of bytes. Then I added a keymap where you only need to get to the line of the encoded secret and press enter to decode it, you can be anywhere on that line. The decoded value is then printed to vim.notify.

Wasn't 100% on how to solve it UX wise so if you have any feedback I'd love that.

RobinCamarasa commented 2 months ago

Thanks it is already really great (except copying the secret to the clipboard found a workaround with :message but it is not ideal). My suggestion for the UX would be to toggle inplace the base 64 encode and decode with <cr> key binding, this would make it easier to copy the secret to the clipboard and manipulate it using nvim. I have however no idea of how easy it is to implement.

Ramilito commented 2 months ago

Yeah that would be really great, I'l give it a shot but tbh it sounds a bit challenging

Ramilito commented 2 months ago

The toggle feature was a bit too much, figuring out if a text is decoded or encoded or keeping track of them isn't worth the hassle imo. Settled on a compromise to only decode and replace the current encoded value, if you want to revert it just close and open the description window. If that's not enough, we might revisit it later, but I feel that it's pretty good where it's at right now!