Publish
When setting up Offline publication, the publication will create a database based on the settings in server.config. The publisher will create a database with the same version as the instance in the settings file.
<SqlServerDatabaseSettings> <PublishToSqlServerLogin> <UseSqlServerUser>false</UseSqlServerUser> <SqlServerUser>Assert#User</SqlServerUser> <SqlServerPassword>Login#123!@$</SqlServerPassword> </PublishToSqlServerLogin> <PublishToInstanceName>MATTIAS-LAPTOP\SQLEXPRESS01</PublishToInstanceName> </SqlServerDatabaseSettings>
Profiling
When the Manger (in standalone mode) or the server (in SE mode) is installed, Offline Viewer is stored in a folder in a profile: C:\ProgramData\Signifikant\Assert\AnyTime
.
Among other thing, it contains a profile information in folder: C:\ProgramData\Signifikant\Assert\AnyTime\Components\Profile
.
Review the content of this folder, since it will be copied to Offline Viewer application data folder after the end user has installed the application. Target folder is: C:\ProgramData\Signifikant\Assert AnyTime\WWWRoot\App_Data
.
Normally, WebViewer has several profiles available, for the server and for each connected site. With Offline Viewer, a simplification is made, providing one profile for the server (application) level. Regardless of the number of sites connected, the one and same profile is used for all sites. Normally this is not an issue since the installation will contain and refer a single site; the DVD publication created in the manager database. But technically, more than one site may be present in an offline installation package and all are potentially installed with the Offline Viewer installation application.
Common profile settings
The App_Data
folder contains files read by the application to provide details of the customer profile; functions in JavaScript, images and style sheets. The profile.config file is the definition file where the profile is declared, referencing other profile files as well. Examples of profile files:
profile.config file: entry point for application profile definitions
customer CSS file: style sheet for the web application
customer JavaScript file: event handlers etc. contributing to web application functions
site logotype file: it will present on all web pages
custom-text.config file: custom translations and text definitions
settings.config: declare, i.e., default site
Note!
Note that browser built in PDF viewer is not functioning very well in Offline client. To avoid these problems, make sure to use pdf.js as PDF viewer and disable browser built in reader. This is done by setting the following properties:
<DefaultPdfJsReader>true</DefaultPdfJsReader> <BrowserPdfReaderEnabled>true</BrowserPdfReaderEnabled>
Synchronization
Note!
Offline synchronization should also be enabled in C:\inetpub\wwwroot\AssertWeb\App_Data\settings.config
<OfflineViewSynchronizationEnabled>true</OfflineViewSynchronizationEnabled> <OfflineSynchronizationSettings> <CertificateSettings> <ChainOfTrust/> </CertificateSettings> <JsonWebTokenSettings> <Audience>Offline</Audience> <DurationInMinutes>10</DurationInMinutes> <Issuer>Offline</Issuer> <Secret>123456789OfflineOfflineOfflineOfflineOffline</Secret> </JsonWebTokenSettings> </OfflineSynchronizationSettings>
Synchronization settings with credentials
If it is needed for end clients to enter username and password to start synchronization, this will have to be configured for the function to work properly. Two settings need to be applied: a resource permission and an authentication provider.
A resource permission “Synchronize” is needed to define which user groups shall have access to the sync function. A sample permission setting is:
<ResourcePermission> <Id>12</Id> <Enabled>true</Enabled> <Name>Synchronize</Name> <Note>Allow to sync off-line data</Note> <Groups> <string>EndUsers</string> </Groups> </ResourcePermission>
Anytime will need to know how users trying to sync shall be authenticated. If Assert's authentication is used, an authentication provider needs to be defined. Note that this authentication provider is valid for the server and not for a site. This setting need to be placed in the profile.config.
<AuthenticationProvider> <AssertAuthenticationProvider /> </AuthenticationProvider>
Synchronization settings without credentials
If end clients shall not have to enter username and password to start synchronization, this will have to be configured for the function to work properly. In this case, profile.config of the sync site will have to include a NullAuthenticationProvider
which allows users to sync without credentials.
<AuthenticationProvider> <AssertNullAuthenticationProvider> <UserName>Unknown</UserName> <Groups> <string>Synchronize</string> </Groups> </AssertNullAuthenticationProvider> </AuthenticationProvider>
Synchronization Authentication
Since the Synchronize API is in version 2, it now relies entirely on authentication tokens to authorize clients. In this case, JSON Web Tokens are used since it is a popular and well-adopted standard.
Version 2 also comes with the possibility to use X509 certificates for authentication. But, regardless whether basic authentication or certificate-based authentication is used, the underlying security layer relies on JSON Web Tokens.
1. Server setup: JSON Web Token
On the server, the JSON Web Token settings need to be configured. This is achieved in the settings.config
file, and the following snippet needs to be added:
<!-- File: settings.config --> <OfflineSynchronizationSettings> <JsonWebTokenSettings> <Issuer>SigAnySync</Issuer> <Audience>SigAnyClient</Audience> <DurationInMinutes>15</DurationInMinutes> <Secret>YOUR_SECRET_HERE</Secret> </JsonWebTokenSettings> </OfflineSynchronizationSettings>
There are four important settings in <JsonWebTokenSettings>
:
Issuer: The name for the entity which is responsible for issuing and validating tokens (unique name, ex: hostname)
Audience: Name of the entity by which the token is intended to be used. (unique name, ex: hostname)
DurationInMinutes: How long a token is considered valid. After it has expired, the client will need to authenticate again. This is done seamlessly in the background and requires no user interaction.
Secret: A Base64 randomly generated string. A length of 128 bytes is recommended. Make sure this is kept secret!
2. Server setup: Certificate-based authentication
In case certificate-based authentication is intended to be used on the synchronization server, you will have to set up the server so that it is able to validate user certificates.
To do so, the server must add the Root Certificate Authority responsible for issuing user certificates to its list of trusted authorities:
Download the certificate of the Root CA. Either check with your certificate provider or get the service URLs from the user certificate.
Install the Root CA on the server. You will likely be asked where to install the certificate, make sure to choose Local Machine and NOT Current User (Reason: IIS has its own current user and will not see the certificate if installed in the user store). For the location, pick “Trusted Root Certificate Authorities”.
Double check that you got the right certificate and that you installed it at the right location
For instructions on how to configure inside anytime.setup.config
, please refer to: Client app configuration (anytime.setup.config)
Customization
When an offline publication is created, Manager will look in this folder to fetch the customizations to use in the offline installation package that is created by the offline publication process.
C:\ProgramData\Signifikant\Assert\AnyTime\Components\Customize
Currently, Assert Anytime customizations will have to be configured by Signifikant.