listen doesnt work on LAN

[unphased]

• I have read through the manual page (man fzf)
• I have the latest version of fzf
• I have searched through the existing issues

Info

• OS
  • Linux
  • Mac OS X
  • Windows
  • Etc.
• Shell
  • bash
  • zsh
  • fish

Problem / Steps to reproduce

I find that I can access fzf --listen server just fine with curl but only on localhost.

I have a use case where I want to do some semi automated file searching, so i use a preview hook to curl a change-query command. Well I often want the backend fzf doing the file list matching to be on a remote host.

I see much discussion around security for --listen which seems reasonable but I think from what I saw in the code, this binds to localhost right now.

I reckon the security is good enough that we can allow network hosts to connect. Maybe we can enforce the use of an auth token to do this?

[junegunn]

Maybe we can enforce the use of an auth token to do this?

Yes, we really should, if we're going to allow external connections. It's so easy to mess up your system through this: execute:rm -rf /

1. Change --listen to take the listen address, not just the port. e.g. 0.0.0.0:0
2. If the address specified is not localhost (or 127.0.0.1), check if FZF_API_KEY is set to a non-empty value.

[unphased]

I'd also be cool with putting execute and such commands locked behind further security gates, like a somewhat long launch flag name. Thanks!!

[junegunn]

Yeah, I also thought about that. We probably have two options:

• Add --listen-safe that doesn't allow process execution
• Add --listen-unsafe which allows remote process execution. Disallow remote (non-localhost) process execution in ordinary --listen ✅

[unphased]

Thanks! I had to get a newer version of go than apt provides, built fzf, and --listen does require 0.0.0.0:<port> instead of just port to allow binding outside localhost, and it works!

[unphased]

One thing I'd like to note is when setting queries to large values and then setting to a smaller value, the horizontal scroll in the search bar isn't reset so it looks a bit wonky. Not a big problem but it made me think there was a huge bug for a few minutes last week.

[junegunn]

You'll see the same result when you hold down the backspace key and erase the query. It can be less confusing because you see the whole process.

I thought curl -d 'change-query(short)+beginning-of-line+end-of-line would reset the scroll offset, but it turns out it doesn't because fzf updates the offset only after the whole series of actions are performed. FWIW, you can first empty the query and set it to a new value in a separate call, but it's far from ideal.

curl localhost:6266 -d'change-query:'
curl localhost:6266 -d'change-query:foo'

[junegunn]

84bb350 is a simple patch that makes the `beginning of line+end of line' trick work as expected. (Ideally, we should be able to handle any action that moves the cursor to the left.)