Release Notes

FirstSpirit uses several standard web applications (fs5root, fs5webedit, fs5webmon, fs5preview, fs5staging) as well as possibly additional, project-local web applications (fs5webedit_PROJECTID and fs5preview_PROJECTID). For (user) authentication FirstSpirit, like most other web applications, uses randomly generated session cookies (see information on the use of cookies).

Many browsers (including Chrome 80) have massively restricted third-party cookies since the beginning of the year. All cookies that do not have the attribute SameSite are causing warning messages. SameSite is a standard that is intended to prevent cookies from being automatically sent by the browser with so-called cross-site requests and thus offers protection against cross-site request forgery (CSRF). In addition to this security aspect, the SameSite attribute allows you to define which cookies can be read in which context.

The FirstSpirit Session Cookie supports the SameSite attribute from FirstSpirit 2020-05 on with the option of configuration (see configuration servletSessionCookieSameSite). The previously recommended default setting (SameSite attribute is not set) can now cause the following log output in the JavaScript console in some browsers:

Cookie “FS52ID” will be soon treated as cross-site cookie (...)

The default setting for the SameSite attribute is changed with FirstSpirit 2020-09 to SameSite=Lax.

With this setting the session cookie is only sent in the first-party context (i.e. only if the page for the cookie matches the URL in the browser) and only together with cross-site requests that are considered “safe”. This applies to secure HTTP methods (GET, HEAD, OPTIONS, and TRACE) and top-level navigation (actions that cause the URL in the browser address bar to change, such as links).

e-Spirit recommends retaining the default settings of the fs-server.conf configuration file. In most cases the default setting covers both security aspects (good protection against cross-site request forgery) and user concerns (good user experience).
Only in exceptional cases (e.g. FirstSpirit as an embedded web app) a change is necessary.

The value for the FirstSpirit Session Cookies can be set via the configuration file fs-server.conf, both globally via the parameter servletSessionCookieSameSite and individually for specific WebApp paths, e.g. servletSessionCookieSameSite.fs5webmon=None for FirstSpirit ServerMonitoring. A WebApp-specific configuration overwrites the global setting servletSessionCookieSameSite for this WebApp path.

When switching from FirstSpirit 2020-08 to another FirstSpirit version, the FirstSpirit server may not be accessible. The web applications log an error message of the type

de.espirit.firstspirit.common.ConnectError: Wrong client version

In this case the web applications should be deleted manually. The following directories can be affected:

• ~/tomcat/webapps
• ~/firstspirit/web
• ~/firstspirit/data/modules/FirstSpirit Jetty Server.JettyService/webapps

The FirstSpirit server can then be restarted.

If you require support, please contact e-Spirit Technical Support (https://help.e-spirit.com).

In the “Comparison View” for a page, changes that have been made to the page can be visualized in the “Show modifications” dialog. This is opened via the “Display differences” icon:

The user guidance when restoring a version has been modified in this dialog (via the “Restore this version” button or icon

Previously, the dialog closed immediately after restoring the version, but now it remains open until the “Restoration succeeded. The current version will now be loaded” information dialog is confirmed with “OK”:

In this way, it is now possible – when using the API (ComparisonDialogOperation interface, de.espirit.firstspirit.webedit.server package, FirstSpirit Developer API) – to hold off on closing the dialog until another action is carried out.

FirstSpirit 2020-09 supports the following module versions for “FirstSpirit Content Experience Tools”:

* These modules require FirstSpirit 2020-03 or higher from this version.

To upload and select media in FragmentCreator, the “FS_INDEX” component is used with the “Media DAP” module. In the current release, entire directory structures (folders), including any images and files of different formats they contain, can be selected for upload instead of just files from the workstation PC.

To do this, the required folder(s) must be moved to the upload dialog using drag-and-drop.
Once the folders have been dropped, all media contained in the folders are displayed in the dialog. This enables the media that are to be referenced in the component to be selected.
Potential restrictions regarding file size and format that have been implemented by the project developer are taken into account directly. Only files which meet the size and format requirements are transferred to the dialog.
The folder path for the media to be uploaded is displayed underneath the media, along with the file name.

Once all the required media have been selected, the upload can be started by clicking “Upload”. The upload dialog closes automatically once the media have been uploaded successfully. Exception: In the event of an error, the dialog stays open, displays a corresponding error message, and the media affected are not uploaded.

In the Media Store in the associated FirstSpirit project, the uploaded media and folders are mapped in the file structure of the workstation PC. Empty folders are not taken into account, however.
For both the media and the folders, the names of the folders and files are used by the workstation PC in each case.

In the current release, FragmentCreator also supports CMS_INPUT_TOGGLE, the input component for switching between two states.

Example:

<CMS_INPUT_TOGGLE name="picture_position" useLanguages="yes">
         <LANGINFOS>
           <LANGINFO lang="*" label="Picture position"/>
           <LANGINFO lang="DE" label="Ausrichtung des Bildes"/>
         </LANGINFOS>
         <OFF>
           <LANGINFO lang="*" label="Right"/>
           <LANGINFO lang="DE" label="Rechts"/>
         </OFF>
         <ON>
           <LANGINFO lang="*" label="Left"/>
           <LANGINFO lang="DE" label="Links"/>
         </ON>
</CMS_INPUT_TOGGLE>

CMS_INPUT_TOGGLE in FragmentCreator

The various states are mapped via the mandatory tags <ON> and <OFF>. A label must be defined for each state via the <LANGINFO> tag.

The radio buttons for the component are displayed one below the other with the <ON> state at the top and the <OFF> state at the bottom. This order cannot be changed.

Note: Unlike in FirstSpirit ContentCreator and SiteArchitect, only the “Radio button” type is supported in FragmentCreator (corresponds to type="RADIO"). The type parameter is not taken into account in FragmentCreator; the input component is always presented as a radio button.

For more information, see https://docs.e-spirit.com/odfs/edocs/cxt/templates/input-component/index.html.

The release of the new database layer Oracle Database 19c, planned for 2020Q3, has been postponed and is now scheduled for 2020Q4.

Currently, the Oracle Database 19c layer is still in the EAP (Early Access Program) phase. The EAP phase will be accompanied through the FirstSpirit Community (https://community.e-spirit.com). Detailed documentation regarding the use of Oracle Database 19c with FirstSpirit is also published in the Community.

In a generation process, data is generated from FirstSpirit elements and is stored in the file system. After one or more generation processes of this nature, it is often necessary to carry out post-processing steps on the generated data. Examples include:

• replacing placeholder media with media from a MAM (controlled via metadata)
• training a search engine using metadata stored for the individual FirstSpirit elements

The new method getOutput()in the GenerationAgent interface (FirstSpirit Developer API, de.espirit.firstspirit.scheduling.agency package) can be used to allocate the generated files to the corresponding FirstSpirit objects after a generation process. This information can be used in a downstream schedule step in order to change the generated data or to forward the information about this data to third-party systems.

Example code (Beanshell):

import de.espirit.firstspirit.scheduling.agency.GenerationAgent;
import de.espirit.firstspirit.agency.LanguageAgent;
import de.espirit.firstspirit.scheduling.agency.FileEntry;
import de.espirit.firstspirit.access.store.IDProvider;

generationAgent = context.requireSpecialist(GenerationAgent.TYPE);
ml = context.requireSpecialist(LanguageAgent.TYPE).getMasterLanguage();
Collection<FileEntry> output = generationAgent.getOutput();
for (entry : output) {
 uid = entry.getElementUid();
 IDProvider.UidType uidType = entry.getElementUidType();
 path = entry.getPath();
 element = entry.getElement(context, false);
 context.logInfo("+ Generated: " + uid + " (" + uidType + ") = " + 
   element.getDisplayName(ml) + " at: " + path);
}

The method getOutput() outputs all data that is located in the generation directory when the script is executed (i.e., the data could potentially be deployed). Multiple previous generations of the schedule are taken into account automatically.

In addition to the output allocation, the PermissionsAgent (FirstSpirit Developer API, de.espirit.firstspirit.access.editor package) has been introduced in order to determine existing access and execution permissions for the individual FirstSpirit objects. These permissions are special user permissions which are specified by the template developer via a project-specific metadata template using the CMS_INPUT_PERMISSION input component and are then defined in the metadata tab of the FirstSpirit objects (they are not editorial permissions which are defined in FirstSpirit). The PermissionsAgent also takes into account the inheritance of these permissions, i.e., permissions which have been inherited from a higher-level node are also read out.

The new rule PROPAGATE_MEDIA_CHANGES_TO_CONTENTSTORE in the DeltaGeneration interface (FirstSpirit Developer API, de.espirit.firstspirit.access.schedule package) can now be used to forward media changes to datasets.

When the rule is used, releasing a medium means that all datasets that reference this medium in the release state are regarded as “changed” for the delta generation.

In the current FirstSpirit release, external users can also be used for password configurations in ServerManager. These passwords can be used both for scripts and for remote connections.

The extension affects all passwords which were explicitly set in remote connections or script tasks in ServerManager.

• In the Schedule management area – in the “Script properties” dialog,
  see Documentation for administrators – FirstSpirit ServerManager / Schedule entry planning / Server-based actions / Execute script
• In the Remote projects area – in the “Edit remote project configuration” dialog,
  see Documentation for Administrators – FirstSpirit ServerManager / Project properties / Remote projects

Note: For security reasons, server administrators cannot be used for the password configuration.

To expand the users, the password format of the PasswordAgent has been changed. This does not affect existing data; the old format can continue to be read. A new authentication only takes place if the password is re-entered in the configuration dialogs. The old login implementation continues to be used with old persistent data.

Note: Forward compatibility is ensured. Once the FirstSpirit Server has been updated to the latest version, all set passwords continue to be valid. It is not necessary to reset the passwords.

Note: If the FirstSpirit Server is downgraded to FirstSpirit version 2020-08 or earlier, encrypted passwords are now no longer compatible via the PasswortAgent and must be reset.

The FirstSpirit Launcher is digitally signed. Thanks to the signature, the customer knows where the application comes from and that it was not manipulated during the transfer (from the manufacturer to the recipient).

In the current FirstSpirit version, the certificate of the FirstSpirit Launcher is updated.