For initialisation of the T1C you need to prepare your application first by adding the SDK JS files to your project and importing them in such a way that you can call for the Javascript functions when you need them. When you've succesfully downloaded and installed the Trust1Connector you can initialize and use the Trust1Connector
We will prepare the SDK's configuration Object, this object is used to pass information about which default port the Trust1Connector is running on, JWT key, API url, ... which is needed to properly contact and use the Trust1Connector.
When the Trust1Connector is configured with a Distribution Service in mind you can provide a valid JWT token in the configuration object. You can retrieve such token via the Distribution Service based on the API key you received.
Retrieving JWT tokens should be handled in your own backend to maximize security
Now we can create a complete Configuration Options object to be passed to the Trust1Connector.
The T1C config options is a class that can be used to create a valid configuration object to initialize the Trust1Connector. Below you can find a class definition.
t1cProxyUrl
and t1cProxyPort
are deprecated since 3.5.x and only used in 3.4.x versions.
t1cApiUrl: string
Optional
The URL that connects to the local Trust1Connector instances. This can be either localhost or a domain that directs towards localhost. By default this will be https://t1c.t1t.io
t1cApiPort: string
Optional
The port defined to be used for the Trust1Connector. By default this is 51983
t1cProxyUrl: string
Optional - Deprecated
The URL that connects to the local Trust1Connector Proxy instances. This can be either localhost or a domain that directs towards localhost. By default this will be https://t1c.t1t.io
t1cProxyPort: string
Optional - Deprecated
The port defined to be used for the Trust1Connector Proxy. By default this is 51983
jwt: string
Optional
The JWT token that is used to authenticate towards the Trust1Connector. This should be retrieved from the DS and is only needed when the Trust1Connector is configured to work with a DS and requires JWT validation
applicationDomain: string
Optional
The domain of the application that is using the Trust1Connector. This is used to make sure the consent is only available for a specific web-application. This prevents various clients to interfere with eachother.
This domain also tags
the Distribution service transactions being sent to the Distribution service. This makes it easy to distinguish between applications/tags for the transactions
When a remote DS is used you can set the following field with the correct DS url, this will in turn use the DS's capabilities of acting as a Trust1Connector proxy for enchanced security.
Now we can continue to use the config
variable to initialize and retrieve a T1CClient
If you need to set up the Trust1Connector with a valid JWT token you can follow the documentation on the Authenticated Client page to retrieve a valid token from the DS.
When you have a valid token you can provide this in the Configuration. This will make sure the Trust1Connector is usable until the token becomes unvalid. At which point you can refresh your token to continue to use the Trust1Connector. More information on how to retrieve,use and refresh a token can be found on the Authenticated Client page.
Initialization of the Trust1Connector in many cases requires a user consent, the exception being when no registry is configured (either local or central). More information can be found here. The registry allowed us to create a Trust1Connector that works in any environment, without the need for Administrative rights from the users, wether it be Standalone, Multi session, RDP, Citrix, ...
To Initialize the Trust1Connector a Consent is required(when a central or local registry is present). When no consent can be found the error codes 814500
or 814501
will be thrown. This means that either the previous consent is not valid anymore or no consent was given yet. More information regarding the consent can be found on the Consent page which explains it in more detail
When either no consent is present or its invalid you will receive a invalid client
object (line 8 in example above) that can be used to trigger the getImplicitConsent
function in the Core serivce.
The Consent requires a user action to copy some data to its clipboard. This data is used by the T1C registry to make sure you're targetting the correct instance of the Trust1Connector. More information about this can be found here.
The signature of the getImplicitConsent
function is as follows;
This function expects:
codeword: string
The string value that is saved to the user's clipboard needs to be sent to the Consent function.
durationInDays: number
Optional
Amount of days that the consent is valid.
callback: (error?: T1CLibException, data?: T1CClient)
Optional
Callback when you're not using ES
Below is a small javascript example of how you can trigger the getImplicitConsent
function
After this you will have a client
that can be used to execute the rest of the functionality that the Trust1Connector has to offer.
To provide a consent, we suggest you use the clipboard functionality available in browsers. The most supported way is via document.exeCommand
and below you can find an example of this.
There is also a clipboard API but this is not fully supported yet
The code below is an example of how you can integrate a copy command in the webbrowser
GET
https://ds.t1t.io/v3/tokens/application
This endpoint will return a valid JWT token to use for a certain period based on the API-key you provide in the `apikey` header
Name | Type | Description |
---|---|---|
apikey
string
API-key received from Trust1Team