4D v11 SQL Release 6 (11.6) ADDENDUM

Transcription

1 ADDENDUM Welcome to release 6 of 4D v11 SQL. This document presents the new features and modifications of this new version of the program. Increased ciphering capacities Release 6 of 4D v11 SQL extends the capacities of 4D applications as far as ciphering is concerned via two new features: A new database parameter can be used to modify the cipher list used by 4D; The GENERATE ENCRYPTION KEYPAIR command can be used to generate keys up to 2048 bits in length. SET DATABASE PARAMETER, Get database parameter A new selector (constant) is available for the SET DATABASE PARAMETER and Get database parameter commands. Selector = 64 (SSL Cipher List) Values: String. Description: This selector can be used to modify or get the cipher list used by 4D for the SSL protocol. For example, you can use this selector to implement SSL 3.0 ciphering algorithms and thus refuse any connections in SSL 2.0. The cipher list is a sequence of strings separated by colons: "RC4-MD5:RC4-64-MD5:..." This setting applies to the entire application (it concerns the HTTP server and the SQL server as well as all the 4D functions that make use of the SSL protocol) but it is temporary (it is not maintained between sessions). When the cipher list has been modified, you will need to restart the server concerned in order for the new settings to be taken into account. 4D v11 SQL Release 6 (11.6) Addendum 1

2 To reset the cipher list to its default value (stored permanently in the SLI file), call the SET DATABASE PARAMETER command and pass an empty string ("") in the value parameter. By default, 4D uses the RC4 cipher algorithm. If you want to use the (more recent) AES algorithm, pass the following string in the value parameter: Note: With the Get database parameter command, the cipher list is returned in the optional stringvalue parameter and the return parameter is always 0. Configuration of 4D in SSL 3.0 only with refusal of SSL 2.0 connections: C_TEXT($ssl3) $ssl3:="null-md5:null-sha:exp-rc4-md5:rc4-md5:rc4-sha: EXP-RC2-CBC-MD5:IDEA-CBC-SHA:EXP-DES-CBC-SHA:DES-CBC-SHA: DES-CBC3-SHA:EXP-EDH-DSS-DES-CBC-SHA:EDH-DSS-CBC-SHA:EDH- DSS-DES-CBC3-SHA:EXP-EDH-RSA-DES-CBC-SHA:EDH-RSA-DES-CBC- SHA:EDH-RSA-DES-CBC3-SHA:EXP-ADH-R"+"C4-MD5:ADH-RC4-MD5: EXP-ADH-DES-CBC-SHA:ADH-DES-CBC-SHA:ADH-DES-CBC3-SHA" SET DATABASE PARAMETER(SSL Cipher List;$ssl3) GENERATE ENCRYPTION KEYPAIR 4D can now generate RSA keys with a length of 2048 bits using the GENERATE ENCRYPTION KEYPAIR command. To do this, you just need to pass the value 2048 in the length parameter. Web Areas WA Execute JavaScript Under Windows, the WA Execute JavaScript command now returns the result of the JavaScript code execution as it does under Mac OS. 2 4D v11 SQL Release 6 (11.6) Addendum

3 Modification of logical mirror architecture Modification of logical mirror architecture Beginning with release 6 of 4D v11 SQL, the mechanisms allowing the implementation of data backup solutions via a logical mirror have been modified. From now on, it is recommended to disable the current log file on the mirror machine. To do this, open the Preferences dialog box of the 4D Server mirror and display the "Backup/Configuration" page. Uncheck the "Use Log File" option and confirm the operation by clicking on the Stop button in the warning dialog box that appears. To allow the implementation of this principle, the INTEGRATE LOG FILE command can now be used without a current log file necessarily being activated. This new principle allows you to avoid a potential risk of desynchronization of the log files in the event of an incident, which became apparent in previous versions of 4D v11 SQL. If you have already implemented a logical mirror solution with 4D v11 SQL, we strongly recommend that you install release 6 on the server and mirror machines and that you modify your development in accordance with the scenario described below. New operating scenario The typical scenario for implementing a backup system with a mirror is now the following (text in italics indicates steps that have been modified with respect to previous versions): Step Operational machine Mirror machine 1 - Start up of the application. - Back up of the data file. - Activation (when necessary) of the log file. 4D creates the MyDatabase.journal file. - The application is exited. - Copy of all the database files (log file included) onto the mirror machine. 4D v11 SQL Release 6 (11.6) Addendum 3

4 2 - Restarting the application (verify that there is not a full backup programmed). - Beginning of operation. - Start up of the mirror application. 4D Server requests the current log file: Select the MyDatabase.journal file that was transferred from the operational database. - Disabling of the current log file on the Backup/Configuration page of the Preferences. 3 - Decision made to update the mirror (for example, after a certain period of operation). - Execution of the method containing the New log file command. The file saved is named MyDatabase[ ].journal. - Sending of the MyDatabase[ ].journal file via programming to the mirror machine (using 4DIC, Web Services, etc.). - The database is operating. 4 - Detection of a file that is waiting to be integrated. - Execution of the method containing the INTEGRATE LOG FILE command in order to integrate the MyDatabase[ ].journal file. 5 - Incident occurs on the machine; the data file is unusable. - Decision made to switch to the mirror machine. - Copy of the current log file MyDatabase.journal onto the mirror machine, via the usual destination folder. 4 4D v11 SQL Release 6 (11.6) Addendum

5 Opening preference (compatibility) 6 - Repair of the machine. - Detection of a file that is waiting to be integrated. Execution of the method containing the INTEGRATE LOG FILE command in order to integrate the MyDatabase.journal file. - As a precaution, creation of a current log file using the Backup/Configuration page of the Preferences. - The database is operating. 7 - The machine is repaired. - Replacement of the database files by those of the mirror database. - Start up of the application. 4D Server requests the log file: Select the file that was transferred from the mirror database. Opening preference (compatibility) - The database is exited. - Return to step 2. The new Allow opening v12 data file option found on the "Database/Data Management" page of the Preferences can be used to set the future possibility of opening data files with 4D v11 SQL r6 that have been converted to version 12 (next major version of 4D): This possibility meets two needs: Ability to develop in v11 a 4D application that is deployed simultaneously in version 11 and in version 12. Ability to reopen, in version 11, an application that was converted into v12 in which data have been entered after the conversion. This operation must be carried out with precaution, in particular if the structure has been modified using new functions of v12. 4D v11 SQL Release 6 (11.6) Addendum 5

6 For security reasons, the No option is selected by default: opening a v12 data file will not be possible. You must explicitly authorize it via the Ask option (displays a confirmation dialog box) or the Yes option (direct opening). Note : Only data files may remain compatible between two versions. A structure file, once it has been converted into v12, can no longer be opened in v D v11 SQL Release 6 (11.6) Addendum