2026 Update Rollup 2

Security Considerations of the Fabasoft Folio Client Web Browser IntegrationPermanent link for this heading

The Fabasoft Folio Client runs as a local process on the workstation in the context of the user currently logged on and may share the user session with a web browser.

Once a user creates a session in the web browser client, the session cookie issued to the user is passed to the Fabasoft Folio Client. To securely pass this information, the Fabasoft Folio web browser extension (Microsoft Edge, Mozilla Firefox and Google Chrome) is used.

Note: This is only valid if a corresponding session cookie has been configured.

Microsoft Edge, Mozilla Firefox and Google ChromePermanent link for this heading

The web browser extension uses the WebExtension API and the native messaging protocol to communicate with the Fabasoft Folio Client. This communication can be restricted to scripts of a specified domain. This is enforced by the Fabasoft Folio Client by validating the source URL. The source URL cannot be manipulated by a script (security mechanism of the web browser extension technology). The native messaging host may only be used by the Fabasoft Folio web browser extension by default configuration.

Apple SafariPermanent link for this heading

The Fabasoft Folio Browser App Extension uses the macOS Framework API to communicate with the Fabasoft Folio Client. In detail a ContentScript (on page), an extension handler (native extension background process) and local socket communication with the Fabasoft Folio UI process is used. This communication can be restricted to scripts of a specified domain. This is enforced by the Fabasoft Folio Client by validating the source URL. The source URL cannot be manipulated by a script (security mechanism of the Safari App Extension technology).

Fabasoft Folio ClientPermanent link for this heading

The Fabasoft Folio Client validates a cookie received from the web browser (expected format, size and parameters) and stores the current value in the cookie store. After the local checks, the cookie is sent to the server, where the authenticity and session information is validated. If the cookie is valid, the Fabasoft Folio Client stores the value in the in-memory cookie store of the HTTP client and uses it for further requests.

Communication SecurityPermanent link for this heading

The communication with the Fabasoft Folio Client is only possible if the respective application was signed with a digital signature certificate and the issuer of this certificate is known to the Fabasoft Folio Client.

Configure the Allowed DomainsPermanent link for this heading

The usage of the Fabasoft Folio Client has to be allowed for specific domains by using the Fabasoft policy "VALIDDOMAINS" (see below). If such a policy does not exist or has an empty value, no domains are allowed by default.

If the policy has a non-empty value, this value has to conform to the syntax given below and will be applied exactly, without adding anything by default.

The registry key for Fabasoft Folio Client policies is as follows:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Fabasoft\NativeClient\Folio

In order to allow domains, this key has to contain the following named value:

"VALIDDOMAINS"="<valid-hosts>"

Syntax:

<valid-hosts>    = <host-pattern> { ( "," | ";" | " " ) <host-pattern> }.
<host-pattern>   = <host-name> [ ":" <port-number> ].

<host-name>      = <host-name-head> { "." <host-name-part> }.

<host-name-head> = <host-name-part> | { <name-char> } "*" { <name-char> }.

<host-name-part> = <name-char> { <name-char> }.

<port-number>    = <digit> { <digit> }.

The string value of VALIDDOMAINS has to consist of a list of host name patterns, separated by semicolons, commas or spaces. Each pattern consists of a host name and an optional port number. Each host name is composed of parts. The first part can contain at most one wild card character "*" according to RFC 6125, section 6.4.1: new window. This wild card character matches a (possibly empty) sequence of characters in exactly the first part of a host name (i.e., it never matches "."). Subsequent parts (other than the first one) must not contain the wild card character. If a host name pattern does not specify a port number, the pattern matches every port.

Examples of valid host name patterns

example.com

Matches exactly the domain “example.com”

sub.example.com

Matches exactly the domain “sub.example.com”

*.example.com

Matches any direct subdomain of “example.com”, e.g.,
“my.example.com” etc.
but not “example.com” itself
and not “sub.my.example.com”

sub*.example.com

Matches “sub.example.com” and e.g.,
“suburb.example.com” etc.
but not “sub.my.example.com”

*sub.example.com

Matches “sub.example.com” and e.g.,
“mysub.example.com” etc.
but not “my.sub.example.com”

s*ub.example.com

Matches “sub.example.com” and e.g.,
“stub.example.com”,
“superdub.example.com” etc.

example.com:443

Matches exactly the domain
“example.com” at exactly port 443