Session Kit Overview
The Session Kit is an SDK focused on managing the connection between applications and Antelope-based accounts through the use of web2-like user sessions.
Its primary responsibilities are:
- To facilitate the signing of transactions by users.
- To allow users to authenticate with web applications.
- To integrate with Antelope-based wallets.
This section of the documentation offers a technical overview of all of the components surfaced by the Session Kit. For step-by-step guides and tutorials, please visit the Session Kit Guides.
The Session Kit exports many classes for use in various types of applications. This page provides a brief overview of the major components, each of which link to their own individual documentation.
The core component of Wharf’s Session Kit is named after the SDK itself and offers itself as a customizable factory class. The SessionKit gives developers methods to generate Session instances in web applications.
The configuration of each Session it generates is based on decisions an end user makes from within a UserInterface (e.g. web, console). The factory process is initiated when the login method is called by the user, which optionally connects and authenticates against external wallets. The result of this call returns a LoginResult containing a Session object that is ready to use within an application to retrieve information about the account and perform transactions.
For any web application that allows users to login with their own wallet, this is a good starting point.
Developers working with the Session Kit will primarily be working with individual Session objects throughout their apps, whether manually defined in an application or created by the SessionKit factory methods. A Session represents the connection between the application and account on an Antelope-based blockchain. Each session offers a Transact method that allows actions to be performed by the account against a given blockchain. The result of this call returns a TransactResult containing the result from the APIClient, including details of the fully crafted Transaction, and any changes the TransactPlugins may have made.
For any Node.js application that internally manages account details, this is a good starting point.
The Session Kit also exports many interfaces for developers to extend and customize the functionality that the kit has to offer. These interfaces are used throughout the plugin architecture to ensure data standards are followed, and to give developers a clear understanding of how various components communicate with one another.
Each WalletPlugin instance provides the required code to facilitate the login method of the SessionKit to create a new session, as well as the means for a Session to perform a transaction using the Transact method. Every Session instance, as well as the SessionKit itself, requires at least one WalletPlugin. This interface provides the structure required by these methods to operate either locally, performing this logic in-app, or through direct communication with an external wallet application.
One or more LoginPlugin instances can be passed to the SessionKit to add new logic during the login call. The interface provides the expected structure of a plugin to allow it to register
afterLogin hooks that allow execution of custom code at specific points of the login process. This can be useful if an application requires additional steps to be performed for user verification, or to pass results to 3rd party services for authentication.
One or more TransactPlugin instances can be passed to either individual Session instances or to the SessionKit in order to add new logic during the Transact call. The interface provides the expected structure of a plugin to allow it to register
afterBroadcast hooks that allow execution of custom code at specific points in the Transact process. These plugins can be useful to perform custom logic either during transactions or after they have been executed.
During instantiation of the SessionKit, one UserInterface instance is required to provide interactivity to the end user during the login process. Optionally, the UserInterface can also provide interactivity during the Transact call, either directly or through the various types of plugins.
The SessionKit utilizes the SessionStorage interface in order to persist Session instances between page loads. The SessionKit does this by default using the BrowserLocalStorage implementation of the interface, which can be overridden during the instantiation of the SessionKit to provide custom means of storage.