Feature request: Send raw FTP / SITE commands from the GUI

[jnewing]

It would be useful to have a way to send arbitrary FTP commands directly over the active FTP control connection from within AeroFTP.

Something similar to FileZilla's custom command / raw command functionality would work well.

For example:

SITE USER <username> <command>

My specific use case is a glFTPd server, which exposes a lot of server administration and user management functionality through SITE commands.

Examples:

SITE USER someuser INFO
SITE WHO
SITE USERS

FTP servers such as glFTPd make extensive use of custom SITE commands that aren't represented by normal file-management operations.

At the moment, there doesn't appear to be a way in AeroFTP's GUI to send these commands through the existing FTP session.

Using the integrated terminal with another FTP client such as lftp works around this, but it creates a separate FTP connection rather than using the session currently open in AeroFTP.

Something in ht UI like

Connection -> Raw Command...

Could open a small dialog containing the command to send? The server response could then be displayed in the dialog, notification area, log, or transfer console.

It would be especially useful if the command were sent through the currently active FTP connection rather than opening another connection.

Since SITE is FTP-specific, I don't think this necessarily needs to become part of the generic StorageProvider interface.

An FTP-specific Tauri/backend command that accesses the current FtpProvider connection may be cleaner.

For commands beginning with:

SITE ...

AeroFTP could either:

• pass the arguments to suppaftp::site(), or
• expose custom_command() for completely arbitrary FTP commands.

It would also probably make sense to use the existing control-channel synchronization / reconnect handling in FtpProvider before issuing the command.

Thanks for considering it.

[axpnet]

Hi @jnewing, thanks for explaining the glFTPd use case. I understand the distinction: our integrated terminal can run another FTP client, but that opens a separate connection. You want to send server-specific commands through the FTP session already open in AeroFTP.

For the design, my preference would be to start with a "SITE Command..." dialog under Connection, available for FTP/FTPS, with the response code and full multiline reply shown together and a copy button. Unrestricted raw FTP commands would need a separate assessment because they can change connection state that AeroFTP manages internally.

Any implementation must use a shared backend operation, with matching CLI support and TUI support where applicable. GUI/CLI parity is a project requirement; this would not be a GUI-only feature. The GUI and TUI should use their existing session, while a standalone CLI invocation would establish its own connection using the selected saved profile.

The operation would need to coordinate with other work on the session, protect sensitive command arguments from persistent history and logs, and avoid automatically repeating an administrative command after an uncertain connection failure. SITE commands can also change server or session state, so their scope needs to be clear.

Could you share the commands you actually need, their exact syntax, and a few representative success/error responses, with private details redacted? In particular, are the user-management operations you need read-only, or do they also modify accounts? That would help us define the scope before committing to an implementation.

Ale

[jnewing]

That design sounds great to me.

A Connection -> SITE Command... dialog restricted to FTP/FTPS would cover what I need. I agree that unrestricted raw FTP commands are a different problem, especially since some of them could interfere with state AeroFTP expects to manage itself.

For my glFTPd use case, I mainly need the standard SITE commands exposed by the server.

One correction to my original example: SITE USER <username> itself is primarily a read-only information command. User changes are done through separate SITE commands.

Some examples of commands I use are:

Read-only

SITE USER <username>

Shows detailed information for a user.

Example response:

200- User Comment: Added by siteop
200- +=======================================================================+
200- | Username: example                   Created: 10-07-26                  |
200- | Added by: siteop                    Expires: Never                     |
200- | Flags: 3                            Idle time: Disabled                |
200- | Ratio: 1:3                         Credits:      10.0 GB              |
200- | Total Logins: 12                   Current Logins: 0                  |
200- | Max Logins: 2                      From same IP: Unlimited            |
200- ...
200- +=======================================================================+
200 Command Successful.

Other read-only examples:

SITE USERS
SITE WHO
SITE FLAGS <username>
SITE SEEN <username>
SITE HELP <command>
SITE VERS
SITE STAT

Account modification

These are also important to me.

Change a user setting:

SITE CHANGE <username> <field> <value>

Examples:

SITE CHANGE example ratio 5
SITE CHANGE example flags +1
SITE CHANGE example max_sim_down 2
SITE CHANGE example num_logins 2 2

Typical successful responses are either:

200 Command Successful.

or a multiline reply such as:

200- Changed max simultaneous downloads for example to 2.
200 Command Successful.

A permission/error case can also still use a 200 reply with the actual error in the text, for example:

200 Invalid Access. Cannot change flags for other SITEOPS.

So displaying both the numeric reply and the complete response body, as you suggested, would definitely be useful.

Other user-management commands I would use include:

SITE ADDUSER <username> <password> [ident@ip]
SITE ADDIP <username> <ident@ip>
SITE DELIP <username> <entry>
SITE CHPASS <username> <password>
SITE CHpgrp <username> <group>
SITE DELUSER <username>
SITE READD <username>
SITE RENUSER <username> <newusername>

For example:

SITE ADDUSER example hunter2 *@192.0.2.*

can return something along the lines of:

200- User created, now adding IPs...
200- IP '*@192.0.2.*' successfully added to example.
200-
200 User (example) successfully added.

And:

SITE CHANGE example max_dlspeed 250

can return:

200- Changed max download speed for example to 250 KB/s
200 Command Successful.

So yes, my use case includes both read-only commands and commands that modify accounts.

I agree with the points you raised about sensitive arguments. SITE ADDUSER, SITE CHPASS, and potentially custom SITE commands can contain passwords or other sensitive values, so I would not expect command arguments to be written to persistent history or normal application logs.

I also agree that mutating SITE commands should not be automatically retried after an uncertain connection failure. For something like SITE ADDUSER, SITE DELUSER, SITE CHANGE, etc., the client cannot safely assume whether the server applied the operation before the connection failed.

From my perspective, the ideal scope would be:

• FTP/FTPS only
• send an arbitrary SITE <arguments> command through the existing session
• GUI and TUI use their current active session
• CLI uses the selected saved profile and establishes its own connection
• display the full multiline response plus FTP reply code
• no persistent command history by default
• no logging of SITE arguments that may contain sensitive values
• no automatic retry of SITE commands after an ambiguous failure
• serialize it with other control-channel operations on the same session

I don't specifically need unrestricted raw FTP commands if generic SITE support is available. For glFTPd, that would cover essentially everything I'm trying to do.

Thanks for taking a look at it.

[axpnet]

Hi @jnewing, SITE commands are in and ship in v4.2.3. Thank you for the detailed command list and the sample replies: they became the test plan, and you are credited as co-author on the commits.

GUI. A new Connection menu has SITE Command..., active only while the current session is a connected FTP or FTPS one and off otherwise, in the app's own menu bar and in the native one (also in the Command Palette, which lists it only then). The dialog sends SITE <arguments> through the session that is already open, so it takes no extra login slot, and keeps a transcript: each command with the reply code and every line of the reply in a monospace view, so your SITE USER box stays aligned. There is a copy button per reply, Copy all, and a toggle to hide the 200- prefixes while reading.

Off without a session, on with an FTPS session (the app's menu bar on top, the native menu below):

The transcript: ADDUSER with its password masked, an unknown command, STAT (226) and USER:

The same transcript with the reply codes hidden:

Terminal. aeroftp-cli site --profile <name> USER example prints the reply as the server sent it (--json for scripts, --strip-codes to drop the prefixes), and --file admin.txt runs one command per line on a single connection. In the TUI, :site USER example opens the reply in the pager.

On the points you raised:

Your requirement	What it does
FTP/FTPS only, through the existing session	The GUI and the TUI use the open session; the CLI opens its own from the saved profile. Any other protocol is refused before anything is sent.
Full multi-line reply plus the code	Every line, in order, with the code read from the reply itself, so codes like 226 (glFTPd's SITE STAT) or 214 (SITE HELP) are shown as replies, not errors.
A 200 can still be a refusal	The code is never turned into a success badge: 1xx-3xx are shown neutral, 4xx/5xx amber, and the dialog says to read the text. The CLI exit code follows the code only (0 for 1xx-3xx, 10 for 4xx/5xx).
No persistent history	The history lives in memory for the session and is cleared on disconnect; commands that carry a password (ADDUSER, GADDUSER, CHPASS, PASSWD) are left out of it, and their password is masked in the transcript.
No logging of arguments	Arguments and reply text are never written to a log; the activity log records the verb and the code only (SITE CHANGE: the server replied 200). On the command line, --secret pw asks for a password without echo and puts it where {pw} appears, so it stays out of your shell history: aeroftp-cli site --profile <name> --secret pw CHPASS example {pw}.
No automatic retry after an ambiguous failure	A command is written once. If the reply does not arrive in time (60 s by default) or the connection drops, the dialog says the outcome is unknown and that the command was not sent again, and the session is re-established without resending it.
Serialized with other control-channel work	One command at a time on the session; if a transfer is holding it, the dialog waits a few seconds and then says the session is busy, instead of hanging.

On a plain FTP session the dialog also warns that arguments, passwords included, cross the network unencrypted.

The activity log records the verb and the code, nothing else:

What I ran. Against a disposable glFTPd 2.16 server over explicit FTPS:

Command	Where	Reply (as shown)
SITE VERS	CLI	200 glFTPd 2.16 ...
SITE USER glftpd	CLI, GUI	27-line box, alignment intact
SITE STAT	CLI, GUI	226- / 226 two-line reply
SITE HELP	CLI	67 lines
SITE FOOBAR	CLI, GUI	500 'SITE FOOBAR': Command not understood. (CLI exit 10)
SITE ADDUSER <user> <password> *@127.0.0.1	CLI (--secret), GUI	200- User created, now adding IPs... / 200- IP '*@127.0.0.1' successfully added to <user>. / 200 User (<user>) successfully added.
SITE CHANGE <user> ratio 5	CLI	200 Command Successful.
SITE CHANGE <user> max_sim_down 2	CLI	200- Changed max simultaneous downloads for <user> to 2. / 200 Command Successful.
SITE CHANGE <user> num_logins 2 2	CLI	200 Command Successful.
SITE FLAGS <user>	CLI	28-line flag table
SITE CHPASS <user> <password>	CLI (--secret)	200- Password Changed... / 200 Command Successful.
SITE DELUSER <user>	CLI, GUI	200 User (<user>) deleted.
SITE PURGE <user>	CLI, GUI	200 User (<user>) purged.

The password never appeared in the terminal output, the log or the dialog's page text. I also ran it against vsftpd over FTPS with a real certificate (SITE HELP, SITE UMASK 022, SITE CHMOD 644 on a test file, and the 550 and 500 cases).

Behind it there are automated tests on a scripted server that records every line it receives, so they check the wire itself: a refused command, a timeout and a dropped connection each reach the server exactly once, a reply followed by extra bytes resynchronises the session, and control characters (CR, LF, NUL...) are refused before anything is sent.

Unrestricted raw FTP commands stay out, as we discussed.

If you can try it on your server and tell me how it behaves with your setup, that would help a lot.

Ale

[axpnet]

Tier B1 from this discussion is on main and queued for v4.2.4.

Tracker: #1202 (comment)

An FTP or FTPS profile can save a SITE command with holes ({name}, {name:number}, {name:secret}) and run it from the CLI (site --template), the TUI palette (:site @name) and the SITE dialog. A secret is a hole: it is not stored, it is not written to history, and the echoed line masks it. A value that contains whitespace is refused before the line is built. Importing the glFTPd catalog leaves a name that is already saved, ignoring ASCII case.

Tests:

CLI, isolated vault, scripted FTP on 127.0.0.1: site --template who sent SITE WHO once and printed 200-who / lab / 200 end.

site --template with --secret echoed SITE CHPASS alice ••••••, put the secret on the wire once, and left it out of stdout and stderr.

--set on a secret slot exited 5 and sent nothing.

site-template add refused a literal password.

A second catalog import added nothing and skipped names already saved, ignoring ASCII case.

GUI, DEV window, same profile over plain FTP: SITE WHO showed 200-who, lab, 200 end.

SITE CHPASS alice •••••• showed 200 password changed. The secret field was cleared, and the secret was absent from the dialog text and from the saved template.

The dialog background matched the other modals on dark, truedark, tokyo, cyber, green and redhorse.

The TUI palette is covered by its unit tests. A live TUI session was not driven. CI on pull request #1205 was green on Linux, Windows and macOS, and the change is 51fbf3b33 on main.