Known issues & limitations

CSRF Detection Issues

Changes were made in 2024 R1 which require more explicit remote host specification in some configurations. For example, if an ADR server is accessed via a proxy webserver, the hostname and protocol of the proxy server must be made available to ADR. These kinds of problems show up in various situations, but two are fairly common. First, if a user tries to log into the ADR server they may be presented with a page reporting a CSRF problem (403 error). Second, it may not be possible to create/update any content in the server (e.g. upload new data, create a new template, etc).

This can be fixed by explicitly telling ADR what hostnames to trust for CSRF purposes. For example, if the ADR server is running behind a proxy server which is used for handling SSL. In cases like this, one will need to set the environmental variable: CEI_NEXUS_TRUSTED_ORIGINS to the domain name(s) of the trusted proxy. For example:

export CEI_NEXUS_TRUSTED_ORIGINS="https://*.example.com"
adr_launcher start --db_directory /my/database/directory

CEI_NEXUS_TRUSTED_ORIGINS is a list of trusted origins for unsafe requests (e.g. POST). It can be of the form https://subdomain.example.com (and/or http://... if requests originate from an insecure page) or https://*.example.com, for example, to allow access from all subdomains of example.com. More than one trusted server can be included by separating them by commas in the environment variable.

Internet Explorer support

The Ansys Dynamic Reporting web application does not support IE.

EnSight & Template Editor

Logging in and out of the ADR Nexus web interface when embedded inside the Ansys Dynamic Reporting Template Editor or EnSight is not supported. Please disconnect from the server using the 'File' menu and reconnect with the new credentials if you would like to switch users.

UNC Paths

ADR Nexus server launched from a UNC location on a Windows system is not supported.

Network Delay Ansys Dynamic Reporting Session Limitations

Integrated operation of Ansys Dynamic Reporting with EnSight and EnVision is reliant upon high performance network connections between the components, display environments (i.e. frames in a browser) and distribution installation location (e.g., network filesystem installs). There are a variety of implied timeouts within and between these components which can disrupt successful launching of these applications within specific environments.

In extended environment testing, some Ansys Dynamic Reporting configurations involving slower VMs and the Firefox web browser have been observed running into problems displaying remote, embedded EnVision sessions. In such cases, switching to browsers with longer default web acknowledgment timeouts (e.g. Chrome) or using higher performance VMs can help. Likewise, problems have been observed when running Ansys Dynamic Reporting from software installations on remote (e.g. NFS) filesystems with slower I/O response or limited remote file locking mechanisms. In these cases, moving the Ansys Dynamic Reporting database and/or the software installation to local disk storage can avoid excessive operational timeouts.

Inability to Create New/Start Databases Under Linux

Ansys Dynamic Reporting relies on the platform specific timezone specification being correct. On some Linux systems, it can be configured in an ambiguous fashion (e.g., different environmental variables point to differently named timezones). On these systems, the Ansys Dynamic Reporting APIs for creating a new database or launching a server may fail. The following test can be used to check to see if the system is misconfigured (use the v242/CEI/bin/cpython Python executable).

import tzlocal
print(tzlocal.get_localzone_name())

If this code raises an exception, the system has been misconfigured. Setting the TZ environmental variable to a valid timezone specification like US/Eastern will work around the issue.