Emitting all events

[Ianpetergreenburg]

Hi, I have been trying to listen to events other than STOR and RETR and noticed that the emit command doesn't get run under any other directive. Is this purposeful or have the features just not been implemented yet?

[trs]

Current it only emits events on STOR and RETR.

Feel free to make a pull request with more commands added!

[Ianpetergreenburg]

will do!

[pablokvitca]

Could we create will and did events for each command? "will" would be emitted before the command runs (maybe with a way to cancel the command and return an error) and "did" after it has run. This can be useful for more specific actions on each command.

[trs]

I like the idea of that. A fleshed out event system would be a good improvement.

[wtho]

Any other ideas that would lead to a fleshed out event system?

Another suggestion: I could make use of a close event on the connection object, independently of the command sent by the client.

[lezsakdomi]

Could add workaround for #114 if we add event listener for unrecognized commands.

[lezsakdomi]

Maybe a hook in src/index.js should be provided before all the white-listing, where we could override whether allow that specific command or not. (command event)

The listeners after a command has been run should be called from every command handler, since only there do we know the result of the operation (i.e. status code, effect on the connection), which would be nice to be passed to the event listener.

I don't know whether a command event should be emitted or not if we don't have any handler for it or only just an event indicating the unknown command.

[BuonStefano]

In my humble opinion it would be great to have an event handling on ExecBeforeCommand as long as on ExectAfterCommand (as ProFTPd does, as example).
I wuold need it because we have a current FTP server (ProFTPd) installed but to be replaced soon.
The problem that we have is that the files requested by the client does not exists on filesystem but are created on-the-fly upon the client request.

With a simple example:

1. client requires file STEFANO.txt to the server
2. file "STEFANO.txt" does not exists on the server but ProFTPd issue the "before RETR" event that's grabbed by an external handler that creates the requested file
3. then can be downloaded by by the server

The external handler is receiving all the connection parameters (client IP, connected username, requested file path, ...) and decide weather to create the file or get an error.

Ref: http://www.proftpd.org/docs/contrib/mod_exec.html#ExecBeforeCommand

[matt-forster]

That is an interesting use case. We would definitely accept a PR attempting something like this!