Implementing FTP User Authentication

To control access to µC/FTPs, there is an authentication callback function that you must implement.

When an FTP client tries to access your µC/FTPs server, it sends a user name and a password. Authentication of these user name and password is out of µC/FTPs’ scope. Thus, these user name and password must be validated and some information about the user’s home directory and browsing permission must be returned by your application.

This authentication is implemented in your application using a callback function (see Chapter 4 for more details):

CPU_BOOLEAN FTPs_AuthUser(FTPs_SESSION_STRUCT *ftp_session);

If that callback function successfully authenticates a user, it must also return two directories information. The firstthe base path, located at ftp_session->BasePath, represents the highest directory in the file system that the user is allowed to see and access. The other one, the relative path, located at ftp_session->RelPath represents the current relative directory for base path that the user sees and access. Here’s some concrete exemples.

  • 1 If you want the user “user1” to access his or her own account “/FTPROOT/home/user1” in the file system and be locked in his or her own account and lower directories (so he or she can’t access the rest of the file system such as other accounts), set the base path to “/FTPROOT/home/user1” and relative path to “/”.
  • 2 If you want the user “user2” to access his or her own account “/FTPROOT/home/user2” in the file system and the rest of the FTP accessible files (assuming that FTPROOT defines the root of FTP accessible files), set base path to “/FTPROOT” and the relative path to “/home/user2”. With that scheme, this user session will start in its account, but he or she is authorized to go up and browse all FTP accessible files, like other accounts.
  • 3 If you want the user “root” to access his or her own account “/FTPROOT/home/root” and all the other file system files, set the base path to “/” and the relative path to “FTPROOT/home/root”. With that scheme, this user session will start on its account, but he or she is authorized to go up and browse all the file system, like other accounts, system configuration files, etc. This scheme can lead to a system security hazard and is thus not recommended.
  • Finally, note that if you want to access the various mass storage devices on your filesystem (RAM disk, SD/MMC, IDE, on-board Flash, etc), you need to create as many users having their base path set to these different devices. For instance, “user1” could access all the RAM disk by setting its base path to “ram:0:” and “user2” the IDE disk with the “ide:0:” base path. Switching from on device to another would then be performed by issuing the “USER” and “PASS” FTP commands.