SSH supports both password-based and public key authentication. Public key authentication is an authentication method that relies on a generated public/private keypair. The keypair is generated using public key cryptography that has the mathematical property that prohibits the same key from encrypting and decrypting the same message. The keys are used at the protocol level for authentication inside SSH during session creation.

It is important to protect the privacy of the private key file. The private key file can be encrypted with a password to ensure that even if someone were to obtain the private key file it would be useless. The SSH public key authentication implementation supports both password protected and unencrypted private key files.

For more information, refer to the new Security Configuration chapter in the QAD .NET UI Administration Guide.

In the QAD .NET UI, screens that display in Desktop mode are based on XML representations of Character UI screens. By default, the XML is posted to Tomcat with an HTTP request to the XMLReceiverServlet for use by the QAD .NET UI. Previously, only HTTP was supported, but now you can use HTTPS instead.

For more information, refer to the new Security Configuration chapter in the QAD .NET UI Administration Guide.

Operating systems can have an upper limit to the number of files or sub-directories that a directory can have. For example, on some versions of Linux, the limit can be 32,768 (32K). Although this limit is almost never reached, in certain circumstances it is possible to approach it. For instance, if your process of adding attachments to programs in the QAD .NET UI is automated in such a way that an attachment is being added for each invoice, over time the default mechanism for storing the attachment files on the home server can approach the operating system’s limit. If you have an automated process for including many attachments and are running the QAD home server on an operating system with a limit that you might exceed, QAD provides an alternative mechanism for storing attachment files.

The alternative approach uses a hashing algorithm such that the number of sub-directories for storing attachments will always be less than 16,384 (16K). With the alternative mechanism, the directory path used for storing attachments (such as invoices) for item numbers in Item Master Maintenance (ppptmt.p) will change from the default path (attachments/domain_/ppptmt.p__/item-number_) to (attachments/32k/domain_/ppptmt.p_/hash/item-number_).

You can configure whether to use the default mechanism by setting <Bypass32kAttachmentLimit> in the client session configuration file (client-session.xml). The default value for this setting is false. If set to true, attachments will be stored using the hashing mechanism.