Session object

The Session object represents the client session itself and it's a very handy object, because it allows you to interact with the actual connection flow.

The Session object is defined as follows:
  TSrvSession = class(TPersistent)
  // [...]
  published
    property ClientIP: AnsiString read fClientIP;
    property ClientSoftware: WideString read fClientSoftware;
    property SID_ProductName: WideString read fSID_ProductName write fSID_ProductName;
    property SID_VendorID: WideString read fSID_VendorID write fSID_VendorID;
    property SID_Version: WideString read fSID_Version write fSID_Version;
    property SID_BuildNo: int64 read fSID_BuildNo write fSID_BuildNo;
    property ReqUsername: WideString read fReqUsername;
    property ReqPassword: WideString read fReqPassword;
    property UserAuthenticated: boolean read fUserAuthenticated write fUserAuthenticated;
    property AllowNextOperation: boolean read fAllowNextOperation write fAllowNextOperation;
    property CustomData: string read fCustomData write fCustomData;
    property CustomDataEx: TStringList read fCustomDataEx;
  end;

The Session object is a very "composite" object, and each property is meaningful or meaningless depending on the event handler that has called the script in which you refer to the Session object itself.

Property name	Scope
ClientIP	always meaningful: contains the IP address of the connected client
ClientSoftware	always meaningful: contains the software name declared by the client upon connection, if any (eg: WinSCP, FileZilla, ...)
SID_ProductName	only meaningful in the "before sending Server ID to client" event handler: used to send a fake server software ID to the client (SSH/SFTP only)
SID_VendorID	only meaningful in the "before sending Server ID to client" event handler: used to send a fake vendor ID to the client (SSH/SFTP only)
SID_Version	only meaningful in the "before sending Server ID to client" event handler: used to send a fake server version number to the client (SSH/SFTP only)
SID_BuildNo	only meaningful in the "before sending Server ID to client" event handler: used to send a fake server build number to the client (SSH/SFTP only)
ReqUsername	the username of the user who has requested to be authenticated (after a successful auth this field contains the username of the connected/authenticated user)
ReqPassword	the password of the user who has requested either a keyboard-interactive or password authentication (empty in case the user has requested a PKI auth)
UserAuthenticated	only meaningful in the following 3 event handlers: •when user requests PKI authentication •when user requests Password authentication •when user requests Keyboard-interactive authentication Setting the UserAuthenticated property to True will actually force the server to consider the user authenticated regardless of his/her key or password. This can be used to add "custom" authentication methods to your Syncplify.me Server! Similarly, setting this property to False, will force the server to consider the user NOT authenticated even when he/she sends a valid PKI or password.
AllowNextOperation	only meaningful in the following event handlers: •before opening a client forwarding channel •before opening a server forwarding channel •before opening a shell •before running a command •before opening the SFTP subsystem •before creating a directory •before listing a directory •before renaming a directory •before deleting a directory •before starting the upload of a file •before starting the download of a file •before opening a file for both upload and download •before renaming a file •before deleting a file The AllowNextOperation property (boolean) is useful when you want to override the limitations defined in the user profile, but only in certain scenarios. For example, assume you want to allow a certain user to upload only jpeg files: in your script you would check if the file is a jpeg and, if so, you will set Session.AllowNextOperation := true, otherwise you will set it to false to prevent the upload of that specific file. This is just an example, you can handle almost any other scenario you can think of (provided there is a way to perform your check).
CustomData	always meaningful: you can put whatever you want in this string-type variable, and bring this information with you
CustomDataEx	always meaningful: an extended multi-line version of the CustomData field, useful for keeping track of multiple objects or metadata throughout the entire session (a script could use this field to store the list of all files that were uploaded in the current session, for example)