All logins, including anonymous connections, are defined by 'Users'. Each user can be configured with various privileges and limitations, which can be completely different for each user.
The image below shows the area that deals with users: pressing the Add or Edit buttons gives access to the screen-shots shown further down this page.
Here various basic aspects of each user are configured, either for a new user, or for an existing user.
Various limitations can be imposed on each user if you wish.
Various permissions with regard to files and directories can be imposed here.
Access configured for a directory is not necessarily inherited by sub-directories, which may be configured with their own set of permissions.
NOTE that initially ALL permissions for a directory will be enabled, also for new directories you create.
A virtual directory does not have to be within the structure shown above of "normal" directories, it can be anywhere in the server machine's filing system, and have any name you give it (rather than its real name on disk).
A user's accessible directories may contain a mixture of "real" directories and virtual directories, but the root directory MUST be a "real" directory.
NOTE that this also give access to all subdirectories of the virtual directory. It is possible to individually configure access to subdirectories (Read, Write, Delete etc) above in the usual way.
NOTE ALSO that the actual directory accessed may be on other machines on your Local Area Network, but be cautious with this:
| • | These other machines may not be running when a user connects - this will produce an error message to the client. |
| • | If another machine is not running Windows, there may be problems with filenames, eg Linux filenames are case-sensitive, unlike Windows. If the user is expecting Window's usual case-insensitivity, they may be in for a shock. |
Cumulative values will be shown here for this user.
Various events can trigger actions (such as playing a sound or sending an email message to warn you of a connection).
Not all events can trigger every type of action because of practical constraints, eg on initial connection before login has been established, as this would break the ftp protocol.
Where an action is configured for a Global Event and a User Event, the action configured for the User Event will override any Global Event.
The Event On Failed Login (introduced with Version 6) is best used here, rather than as a Global Event.
Events - Send an email message
NOTE that the server specified on the General Tab will be used to send any email messages configured here.
Events - Run an Application (Command)
The text file specified will be sent to the FTP client - NOTE that it may not be seen if a browser is used.
NOTE that this file must be in the current working directory.
Events - Add Line to Custom Log File
This allows users to be deleted or disabled after a certain date etc.
NOTE that a check for users set to expire is only run once every 24 hours, so changes may not be made as soon as you expect them.
This enables the User to have their own Key Pair, rather than using the server's.
Normally, when a secure (encrypted) connection is made, it is the server's Key Pair that are used, but if the User's Public Key is pasted into the field here, this will be used in conjunction with the User's Private Key - to which only he or she have access.
Some FTP Clients will generate Key Pairs, and handle the encryption, if configured to do so, but this is not supported by all FTP Clients.
The advantage of this method of encryption is that the User can be sure the encryption is secure (as long as they have properly guarded access to they Private Key), eliminating any risk that the server's keys have become insecure.
Different Key Pairs could be used with different servers.