Topics: |
Reference: |
To configure a FTP Server listener:
For a complete description of the configuration parameters that are available for the FTP Server listener, see FTP Server Listener Configuration Parameters.
For a complete description of the FTP Server listener Special Registers (SREGs), see FTP Server Listener Special Registers.
The following table lists and describes parameters for the FTP Server listener.
Note: Parameters that are common to FTP Server listeners are described in Listener Configuration Parameters.
Parameter |
Definition |
---|---|
Port* |
The TCP port for receipt of FTP requests. FTP standard is port 21. |
Passive Port Range |
Range of ports to which to limit the PASV/EPSV command. This field may contain a range of ports from 0 through 65535 separated by a dash character (-). For example, 30000-40000 or 2200-3000. No entry provides unrestricted access, and any available port between 0 and 65535 may be used. Use this parameter if your server or firewall environment restricts the assignable ports controlled by the server for passive FTP requests. |
Local Bind Address |
The local bind address for multi-homed hosts. Usually leave empty. |
FTP Server Log |
A log of server commands received, and the results of each command. |
Server Root |
The base directory for this FTP Server. When user mailbox paths are relative, they are below this directory. |
Allow Anonymous |
If set to true, then anonymous login is permitted. Anonymous users inherit the default read and write security. |
Use Safestore |
The Safestore preserves store requests while the incoming document is passing through execution. It is not meaningful for direct writes of messages to the file system. Using safestore can reduce system performance. |
Users |
|
Authentication Realm |
Enter the name of the configured Authentication Realm provider. If left blank, then the user and their authentication credentials must be maintained in the FTP Server user repository. |
Repository Type |
This determines how the user repository is stored. The repository can be stored either as an XML file or as a JDBC database. |
Security File [JDBC URL] (required) |
The security file location. The security file describes users permitted to exchange messages with this server. It also describes their mailbox and security characteristics. This is a JDBC or a file URL depending upon the repository type. |
JDBC Provider |
The name of the iWay JDBC provider. |
JDBC Driver |
The JDBC driver to use for accessing the repository. This is required if repository type is JDBC. |
JDBC User Name |
The password for accessing the JDBC repository. Required if repository type is JDBC. |
JDBC Password |
Select one of the following values from the drop-down list:
|
Default Permissions |
|
Default Can READ |
If set to true, then users without specific security can read. |
Default Can WRITE |
If set to true, then users without specific security can write. |
Action on GET |
How the server should treat file retrieve type requests from the client. |
Action on PUT |
How the server should treat file store type requests from the client. |
SITE EXEC |
If set to true, clients can execute processes using the SITE EXEC command. |
Security |
|
Session Timeout * |
If a value greater than 0 is set, then that value is the maximum number of seconds between commands before the session automatically times out. |
Require Secure Auth |
The login must be through a secure authorization channel. You will need to configure the Keystore under HTTPS section of the system properties if client authentication is required. Note, if keystore is configured in system properties make sure it has the CA certificate or the client certificate of the server you are connecting to. If keystore is not configured in system properties default truststore located under /lib/security/cacerts will be used. |
Security Provider |
Enter the iWay keystore or SSL context security provider name. If this component is secure and no value is entered, then the default security provider is used. |
Require Secure Transfer |
The data transfers must be through a secured channel. You must configure the keystore under HTTPS section of the system properties if client authentication is required. Note, if keystore is configured in system properties make sure it has the CA certificate or the client certificate of the server you are connecting to. If keystore is not configured in system properties default truststore located under /lib/security/cacerts will be used. |
Use 128-bit Encryption |
This enforces the use of 128-bit encryption for all TLS channels. |
Security Protocol |
The minimal security protocol supported for FTPS. |
Note: The FTP Server listener supports streaming. Streaming is used for large documents or documents for which the application needs to split the input into sections under the same transaction. For more information on streaming and configuring streaming preparsers, see the iWay Service Manager Component and Functional Language Reference Guide.
The following table lists and describes the Special Registers (SREGs) available on the FTP Server listener.
Name |
Level |
Type |
Description |
---|---|---|---|
ftpd.command |
Document |
String |
The name of the command. |
ftpd.file |
Document |
String |
The file name part of the command. |
ftpd.mode |
Document |
String |
The current transfer mode (ASCII or Binary). |
ftpd.user |
Document |
String |
The user ID of the sender. |
ip |
Document |
String |
The IP address of the sender. |
iwayconfig |
System |
String |
The current active configuration name. |
msgcount |
Document |
String |
The number of messages executed. |
msgsize |
Document |
Integer |
The physical length of the message payload. |
name |
System |
String |
The assigned name of the master (listener). |
pdm |
Document |
String |
If this is a possible duplicate message, 1 is displayed. |
protocol |
System |
String |
The protocol on which message was received. |
source |
Document |
String |
The host name of the sender. |
tid |
Document |
String |
Unique transaction ID. |
Client GET (and MGET) requests the return of information to the client by the server. A GET client for a file can be handled differently, depending on the current settings for the action. The default setting is configured for the listener but it can be overridden for any specific user in the security file.
Use File System
This is a standard FTP retrieval. Data is returned from the named file in the file system.
For example:
ftp> get test.xml 200 PORT command successful. 150 ASCII data connection for test.xml (172.30.246.86,4071) (42 bytes). 226 ASCII transfer complete (42 bytes). ftp: 42 bytes received in 0.00Seconds 42000.00Kbytes/sec.
Test.xml was retrieved from the FTPServer and sent to the FTP client.
Execute as a Message
A standardized XML ftpd request document is constructed containing the request. This document is passed to the system for execution. The result of the execution is returned to the client.
For example, create a process flow that contains a MQEmit service object. Add the process flow to the FTPServer channel.
ftp> get test.xml 200 PORT command successful. 150 ASCII data connection for /test.xml (172.30.246.86,4150) (0 bytes). 226 ASCII transfer complete ftp: 1144 bytes received in 0.05Seconds 24.34Kbytes/sec.
The following document is constructed and passed to the process flow.
<ftpd user="user" type="get"> <command>retr</command> <parm>/test.xml</parm> </ftpd>
The process flow emits the above document to a MQ queue. The status document (shown below) is returned to the FTP client as test.xml.
<?xml version="1.0" encoding="ISO-8859-1" ?> <emitstatus status="0"> <protocol>MQ</protocol> <parms> <parm name="attribs">true</parm><parm name="ccsid"/> <parm name="channel">SYSTEM.DEF.SVRCONN</parm> <parm name="cipherspec">None</parm><parm name="correlid"/> <parm name="correlidtag"/><parm name="expiry"/> <parm name="format"/><parm name="host"/> <parm name="localtrans">true</parm> <parm name="manager">qm7</parm> <parm name="neverUseMaster">true</parm> <parm name="nopreemit">true</parm> <parm name="persist">queue</parm> <parm name="port">1414</parm> <parm name="priority"/> <parm name="queue">out</parm> <parm name="reportq"/> <parm name="reqcoa">false</parm> <parm name="reqcod">false</parm> <parm name="return">status</parm> <parm name="type">datagram</parm> <parm name="userregs">false</parm> <parm name="version">default</parm> <parm name="wanteos">false</parm> </parms> <timestamp>2010-11-29T21:25:51.800Z</timestamp> <status>0</status> <channel>ftpserver</channel> <nodename>com.ibi.agents.XDMQEmitAgent</nodename> <msgid>base64(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)</msgid> <native>0</native> <correlid>base64(QU1RIHFtNyAgICAgICAgIBIu7UwgPXwF)</correlid> </emitstatus>
Deny Access to This Service
The user may not execute a retrieval.
For example:
ftp> get test.xml 200 PORT command successful. 553 'test.xml': cannot read. Test.xml was not retrieved.
Use File System Then Execute a Message
The retrieval operates as a standard FTP retrieval. Data is returned from the named file in the file system. Then, a standardized XML ftpd request document is constructed containing the request. This document is passed to the system for execution. The result of the execution is sent to the configured emitter.
For example, create a process flow that contains a MQEmit service object. Add the process flow to the FTPServer channel.
ftp> get test.xml 200 PORT command successful. 150 ASCII data connection for /test.xml (172.30.246.86,4150) (0 bytes). 226 ASCII transfer complete ftp: 1144 bytes received in 0.05Seconds 24.34Kbytes/sec.
Test.xml was retrieved from the FTPServer and returned to the FTP client. In addition, the following document is constructed:
<ftpd user="user" type="get"> <command>retr</command> <parm>/test.xml</parm> </ftpd>
The document is passed to the process flow. The process flow emits the above document to a MQ queue. The following status document is returned from the process flow and sent to any configured emitters:
<?xml version="1.0" encoding="ISO-8859-1" ?> <emitstatus status="0"> <protocol>MQ</protocol> <parms> <parm name="attribs">true</parm><parm name="ccsid"/> <parm name="channel">SYSTEM.DEF.SVRCONN</parm> <parm name="cipherspec">None</parm><parm name="correlid"/> <parm name="correlidtag"/><parm name="expiry"/> <parm name="format"/><parm name="host"/> <parm name="localtrans">true</parm> <parm name="manager">qm7</parm> <parm name="neverUseMaster">true</parm> <parm name="nopreemit">true</parm> <parm name="persist">queue</parm> <parm name="port">1414</parm> <parm name="priority"/> <parm name="queue">out</parm> <parm name="reportq"/> <parm name="reqcoa">false</parm> <parm name="reqcod">false</parm> <parm name="return">status</parm> <parm name="type">datagram</parm> <parm name="userregs">false</parm> <parm name="version">default</parm> <parm name="wanteos">false</parm> </parms> <timestamp>2010-11-29T21:25:51.800Z</timestamp> <status>0</status> <channel>ftpserver</channel> <nodename>com.ibi.agents.XDMQEmitAgent</nodename> <msgid>base64(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)</msgid> <native>0</native> <correlid>base64(QU1RIHFtNyAgICAgICAgIBIu7UwgPXwF)</correlid> </emitstatus>
Client PUT (including append) cause the transfer of information from the client to the server. A client PUT request can be handled differently, depending upon the current setting for this action. The default setting is configured for the listener but it can be overridden for any specific user.
Use File System
The request operates as a standard FTP store command. Data is stored from the named file in the file system.
For example:
ftp> put test.xml 200 PORT command successful. 150 ASCII data connection for /test.xml (172.30.246.86,4242). 226 ASCII /test.xml transfer complete (42 bytes) ftp: 42 bytes sent in 0.00Seconds 42000.00Kbytes/sec.
Test.xml was sent to the FTPServer and saved in the server root directory.
Execute as a Message
The data is passed, as a document, into the system for execution. A standardized XML document is constructed containing the data. This document is passed to the system for execution.
For example, create a process flow that contains a MQEmit service object. Add the process flow to the FTPServer channel.
ftp> put test.xml 200 PORT command successful. 150 ASCII data connection for test.xml (172.30.246.86,4288). 226 'STOR EXEC entered for test.xml': was successful. ftp: 42 bytes sent in 0.00Seconds 42000.00Kbytes/sec.
Test.xml was sent to the FTPServer. It is then passed to the configured process flow which emits the document to an MQ queue.
A 451 error code is returned to the FTP client when an error occurs in the process flow. For example:
ftp> put test.xml 200 PORT command successful. 150 ASCII data connection for test.xml (172.30.246.86,1060). 451 'STOR EXEC entered for test.xml': had an execution error! ftp: 1144 bytes sent in 0.00Seconds 1144000.00Kbytes/sec.
An example of this type of error is when an MQEmit service object attempts to send a document to a queue that does not exist.
Deny Access to This Service
This user may not store a file.
For example:
ftp> put test.xml 200 PORT command successful. 553 'test.xml': cannot write. (DENY)
Test.xml was not sent to the FTPServer.
Use File System Then Execute a Message
The retrieval operates as a standard FTP store command. Data is stored from the named file in the file system. Then, a standardized XML ftpd request document is constructed containing the request. This document is passed to the system for execution. The result of the execution is sent to the configured emitter.
For example, create a process flow that contains a MQEmit service object. Add the process flow to the FTPServer channel.
Test.xml was sent to the FTPServer and saved in the server root directory. In addition, the following document is constructed:
<ftpd user="user" type="signal"> <command>STOR</command> <parm>/test.xml</parm> <status>226 ASCII /test.xml transfer complete (42 bytes)</status> <path>c:\ftpserver\test.xml</path> <vpath>/test.xml</vpath> <transfersize>42</transfersize> </ftpd>
The document is passed to the process flow. The process flow emits the above document to a MQ queue. The status document (shown below) is returned from the process flow and sent to the emitter (if one is configured).
<?xml version="1.0" encoding="ISO-8859-1" ?> <emitstatus status="0"> <protocol>MQ</protocol> <parms> <parm name="attribs">true</parm><parm name="ccsid"/> <parm name="channel">SYSTEM.DEF.SVRCONN</parm> <parm name="cipherspec">None</parm><parm name="correlid"/> <parm name="correlidtag"/><parm name="expiry"/> <parm name="format"/><parm name="host"/> <parm name="localtrans">true</parm> <parm name="manager">qm7</parm> <parm name="neverUseMaster">true</parm> <parm name="nopreemit">true</parm> <parm name="persist">queue</parm> <parm name="port">1414</parm> <parm name="priority"/> <parm name="queue">out</parm> <parm name="reportq"/> <parm name="reqcoa">false</parm> <parm name="reqcod">false</parm> <parm name="return">status</parm> <parm name="type">datagram</parm> <parm name="userregs">false</parm> <parm name="version">default</parm> <parm name="wanteos">false</parm> </parms> <timestamp>2010-11-29T21:25:51.800Z</timestamp> <status>0</status> <channel>ftpserver</channel> <nodename>com.ibi.agents.XDMQEmitAgent</nodename> <msgid>base64(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)</msgid> <native>0</native> <correlid>base64(QU1RIHFtNyAgICAgICAgIBIu7UwgPXwF)</correlid> </emitstatus>
Applications should, of course, always be designed to handle errors and manage the return from the listener to the client. Should a process flow report a failure, however, the FTP Server listener presents the error to the FTP client following standards of FTP, with a resultant error code of 451. Given an FTP Server listener configured to EXEC the message to a process flow which fails of the GET EXEC, the transient file on the server is not deleted, and the response seen by a line client (in this case Microsoft FTP client) is as follows:
ftp> get ftpserver036_trans_fail.txt 200 EPRT command successful. 150 ASCII data connection for /signal/ftpserver036_trans_fail.txt (0:0:0:0:0:0:0:1,53940) (0 bytes). 451 ASCII Errors in process were reported. ftp: 390 bytes received in 0.05Seconds 7.22Kbytes/sec. ftp>
Topics: |
How to: |
The security file (in XML format) is loaded when the listener is initialized. This XML file describes the users that are allowed and their attributes. The XML file contains one <user> element for each authorized user, and attributes of the <user> element are used to describe the user. Each user can be a member of one group, which applies the access group criteria that can then be modified on an individual basis. The format for the <access> element allows the specification of the use attribute. The name of the directory to which the access applies is entered as the value for the <access> element.
Any user can have controlled access. Permissions are applied to the specified subdirectory, which is below the document root of a user, and to all remaining directories below this subdirectory. If a permission is not specified, it is taken from the specification of a parent. Permissions are specified by the use attribute of the <access> child of the user. Possible access types are read ('r'), and write ('w'). Read permission permits the client to list directories and access files. Write permission permits file storage and the ability to manipulate directories. Either type can be preceded by a minus sign (-), which removes the permission. A plus sign (+) is implied if the minus is omitted.
To add read and write permissions, specify:
use='rw'
To accept the read permission of the parent and turn off write permission, specify:
use='-w'
The order of the characters is not significant.
The following diagram illustrates a sample FTP directory structure that is referred to in the XML security file example.
The following is a sample XML file that represents the content of a security file:
<ftp> <users> <!-- u1 user has same permissions as g1 group, but set at user level --> <user password="pw" init="/steve" use="rw">u1 <access use="rw-du">/steve/in</access> <access use="r-w-d">/steve/out</access> <access use="v-r-w">/common</access> <access use="r">/common/in</access> <access use="-r-w-v">/*</access> </user> <!-- user john is exactly like u1 (except that he starts in /john directory) but permissions from group --> <user password="pw" group="g1">john</user> <!-- user steve is exactly like john, with two exceptions (overriding group defaults) --> <user password="pw" group="g1">steve <access use="rwd">/steve/in</access> <access use="rw">/common/in</access> </user> <!-- user u2 is like group g2, with specified home directory below docroot. Note that when home is used, init and permission paths are from the user (or group) home, NOT from docroot, while home is from docroot. --> <user password="pw" init="/steve1" home="/subroot" use="v-r-w-d">u2 <access use="rw-du">/steve1/in</access> <access use="r-w-d">/steve1/out</access> <access use="v-r-w">/common1</access> <access use="r">/common1/in</access> <access use="-v-r-w">/*</access> </user> <!-- john1 has g2 permissions --> <user password="pw" group="g2">john1</user>
<!-- steve1 has g2 permissions with override. keep in mind that g2 specifies non-docroot home, so paths are from home, not docroot. --> <user password="pw" group="g2">steve1 <access use="rwd">/steve1/in</access> <access use="rw">/common1/in</access> </user> <!-- u3 is similar to u2, except starts in /subroot, no init pos. --> <user password="pw" home="/subroot" use="vw-d-ru">u3 <access use="rwduv">/u3</access> <access use="-r-w-v">/*</access> </user> <user password="pw" group="g3">u4</user> </users> <groups> <!-- g1 group has same permissions as u1, generalized with $user pattern --> <group init="/$user" use="v-r-w-d">g1 <access use="rw-d">/$user/in</access> <access use="r-w-d">/$user/out</access> <access use="v-r-w">/common</access> <access use="r">/common/in</access> <access use="-r-w-v">/*</access> </group> <!-- g2 group much like g1, but home dir is /subroot and all paths are beneath it --> <group init="/$user" home="/subroot" use="v-r-w-d">g2 <access use="rw-d">/$user/in</access> <access use="r-w-d">/$user/out</access> <access use="v-r-w">/common1</access> <access use="r">/common1/in</access> <access use="-v-r-w">/*</access> </group> <!-- log into (virtual) root w/write, but not read permission. change to use subdirectory with full priv. except overwrite, but venture nowhere else --> <group home="/subroot" use="vw-d-ru">g3 <access use="rwduv">/$user</access> <access use="-r-w-v">/*</access> </group> </groups> </ftp>
Note: This sample XML security file describes several different types of users, illustrating some common usage patterns.
For the users u1, steve, and john in the sample security file:
Users u1 and john differ only in that permissions of u1 are assigned to him directly, while john inherits them from the g1 group. User steve differs from john because he has access permissions for the /common/in and /steve/in directories that override the group g1 defaults.
For the users u2, steve1, and john1 in the sample security file:
For the users u3 and u4 in the sample security file:
The following table lists and describes the permission flags that are used in the sample security file:
Flag |
Description |
---|---|
v |
Signifies visit and view access. Without the v flag set on a directory, a user cannot change to that directory or list its contents. The v flag is set by default and must be revoked explicitly. |
r |
Signifies that a user can retrieve files from the specified directory. |
w |
Signifies that a user can store files in the specified directory. |
d |
When d is set on a directory, a user can delete files from that directory. |
u |
When a directory has the u flag set, a user cannot overwrite a file in that directory. |
m |
Signifies that the user can modify directories, by creating new directories and renaming existing ones. The -m flag is set by default and must be granted explicitly. |
Note: The ‘-’ character revokes the specific permission. For example, -d revokes the delete permission for that directory, -r revokes the read permission.
Access Tree Notes:
User configuration information can be stored in any relational database that is accessible through JDBC. To configure the user database:
Command |
Description |
---|---|
userfile |
Path to the XML user configuration file you wish to migrate. |
op: operation |
Specify one of the following operations:
|
driver |
Name of JDBC driver class. |
url |
JDBC connection URL for the user database. |
u |
User ID that is used to connect to the user database. Must have insert/update/delete permission for user database tables. |
pwd |
Password that is used to connect to the user database. |
For example:
Enter command:>tool MigrateFTPUsers -userfile c:/working/ftptest/userfile.xml -driver com.mysql.jdbc.Driver -url jdbc:mysql:///iwftp -u root -pwd harrison -op upsert
or:
Enter command:>tool MigrateFTPUsers -p c:/working/mp.txt -userfile c:/working/ftptest/userfile.xml -op upsert
The mp.txt file that is referred to in this example can have the following structure and format:
driver=com.mysql.jdbc.Driver url= jdbc:mysql:///itm_db user=steve password=secret
Topics: |
How to: |
User information can be stored in a small relational database consisting of four tables:
The iwftp_owners table defines users and groups that can access the server. The fields are listed and described in the following table:
Field |
Type |
Description |
---|---|---|
iw_ownername |
varchar(45) |
The name (identifier) of the user or group. |
iw_ownertype |
char(1) |
Specify G for group or U for user. |
iw_password |
varchar(45) |
Password for FTP login, required for User (not for group). |
iw_isanon |
integer |
Specify 1 if this user definition should be used for anonymous logins, or 0 otherwise. |
iw_fullname |
varchar(45) |
The long (full) identifier for the user. |
iw_partner |
varchar(45) |
The reference to a partner agreement defined in iWay Trading Manager. |
iw_groupname |
varchar(45) |
For users, the group to which they belong. |
iw_comment |
varchar(45) |
The documentation for the owner. |
iw_home |
varchar(45) |
The home directory is the root of the virtual file system for the owner. |
iw_initialposition |
varchar(45) |
The directory where the owner should be positioned at login. |
iw_getaction |
integer |
The action of the server on RETR command (0 is system default, 1 is exec, 2 is signal, and 3 is file). |
iw_putaction |
integer |
The action of the server on STOR command (0 is system default, 1 is exec, 2 is signal, and 3 is file). |
iw_canread |
integer |
Default read permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_canwrite |
integer |
Default write permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_candelete |
integer |
Default delete permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_canoverwrite |
integer |
Default overwrite permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_canvisit |
integer |
Default visit permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_canmod |
integer |
Default directory modify permission for this owner (0 for no, 1 for yes, and 2 for not set). |
The iwftp_permissions table defines resources to which an owner has access and the specific constraints on that access. The fields are listed and described in the following table:
Field |
Type |
Description |
---|---|---|
iw_owner |
varchar(45) |
User or group to which this permission entry applies. Foreign key for iwftp_owners.iw_ownername. |
iw_ownertype |
char(1) |
Specify G for group or U for user. Foreign key for iwftp_owners.iw_ownertype. |
iw_resource |
varchar(45) |
Name of the directory for which access should be defined. Enter with an absolute path using the virtual file system of the owner. |
iw_canread |
integer |
Default read permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_canwrite |
integer |
Default write permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_candelete |
integer |
Default delete permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_canoverwrite |
integer |
Default overwrite permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_canvisit |
integer |
Default visit permission for this owner (0 for no, 1 for yes, and 2 for not set). |
iw_canmod |
integer |
Default directory modify permission for this owner (0 for no, 1 for yes, and 2 for not set). |
The iwftp_user_hosts table defines host names or IP addresses from which a specific user can connect to the server. The fields are listed and described in the following table:
Field |
Type |
Description |
---|---|---|
iw_username |
varchar(45) |
User or group for which this host entry applies. Foreign key for iwftp_owners.iw_ownername. |
iw_hostname |
varchar(45) |
Host name or IP address from which this user can connect to the server. |
The iwftp_templates table defines patterns that can be used as shorthand when configuring users or groups. The fields are listed and described in the following table:
Field |
Type |
Description |
---|---|---|
iw_templatename |
varchar(45) |
The identifier for this template. |
iw_templatepattern |
varchar(45) |
The substitution string for this template. |
The iwftp_owners table defines an owner and the permissions of the owner regardless of resource. The type of the owner may be { ‘U’ | ’G’ }. The primary key is: `iw_ownername`, `iw_ownertype`
The iwftp_permissions table defines the resource and permissions of an owner or group. The primary key has three fields: {iw_owner=‘user or group name’, iw_ownertype={‘U’ | ‘G’}, iw_resource}
The iwftp_user_hosts table defines a resource and a user name, of which the user name may be a group or a specific user. The primary key is: iw_username
If you are using only individual user names, then ‘iw_groupname’ can be blank , and “iwftp. iwftp_permissions” and “iwftp.iwftp_user_hosts“ should be defined using the same user name(s).
If you are using group names, then define a group name or names before defining users in “iwftp.iwftp_owners”.
When individual users are entered in “iwftp.iwftp_owners”, the owner name is defined in the “iw_ownername” field, and the group name must be entered in the “ iw_groupname” field.
There is no explicit ‘groups’ table, so iw_groupname behaves as a foreign key. However, there is no explicit definition in SQL like “FOREIGN KEY (iw_groupname) REFERENCES “iwftp_permissions (iw_owner)”. It is a non-explicitly defined (no direct SQL) virtual foreign key relationship.
Example: Single User (No Groups)
iwftp_owners
iw_ownername |
iw_ownertype |
iw_groupname |
'Smith' |
'U' |
null |
iwftp_permissions
iw_ownername |
iw_ownertype |
iw_resource |
'Smith' |
'U' |
'linux' |
iwftp_user_hosts
iw_username |
iw_hostname |
'Smith' |
'111.222.2342' |
Example: Using Groups
iwftp_owners
iw_ownername |
iw_ownertype |
iw_groupname |
'DocUser' |
'G' |
'DocUser' |
iw_ownername |
iw_ownertype |
iw_groupname |
'Smith' |
'U' |
'DocUser' |
iwftp_permissions
iw_ownername |
iw_ownertype |
iw_groupname |
'DocUser' |
'G' |
'DocUser' |
iwftp_user_hosts
iw_username |
iw_hostname |
'DocUser' |
'111.222.2342' |
iwftp_permissions
iw_ownername |
iw_ownertype |
iw_resource |
'DocUser' |
'G' |
'iwsys1' |
Both:
iw_ownername |
iw_ownertype |
iw_resource |
'DocUser' |
'G' |
'iwsys1' |
To configure for anonymous access:
It is customary to name this user anonymous. However, you may use any name you wish.
<user anonxx="true" home="/common" use="v-r-w-d">anonymous</user>
When the anonymous user logs in, he is prompted for a password. Any string containing the @ character is accepted.
If the path specified in the <home> element is absolute (for example, a physical location on a disk, such as d:/a/b), then the server root parameter on the listener is ignored and the user home is at and below the physical location specified. If the location is not absolute, then the home is below the server root (configured on the listener). In all cases, the user is restricted to the final home location. iWay recommends that only administrators receive physical home locations that permit access to data other than message data.
SITE is a server-specific command that can be called by clients to execute some site-specific function. The FTPServer supports SITE for the following purposes. The SITE verb itself may or may not be inserted by the specific client in use. The means by which such site-specific commands are requested differs for individual clients. The following table lists available SITE commands.
Command |
Description |
---|---|
SITE MIME filename |
Returns the MIME-type of the named file. |
SITE EXEC [parameters] |
The password for the user. Can be a function reference, such as LDAP(). |
SITE REGISTER [type] name value |
Creates or loads the special register. The type must be set to USR, HDR, or DOC. |
A client needs specific permission to use the SITE EXEC command. Overall permission is set using the listener configuration, and can be overridden for a specific user through the user for or TPA.
Each command executed by the server can be logged. This log takes the following format:
2006-01-29T16:20:12Z 1 USER joe : 331 Password required for joe (667c768105d92c18).
2006-01-29T16:20:14Z 1 PASS ---- : 230 User joe logged in.
2006-01-29T16:20:16Z 1 PORT 127,0,0,1,15,10 : 200 PORT command successful.
2006-01-29T16:20:16Z 1 LIST : 226 ASCII transfer complete.
Each line in the log represents one command, using the following format: