TeamDrive Client <–> Server interaction

User account

Create a new account

A user can use the standard TeamDrive Client to create a new account. So that their account will be registered on the correct Registration Server and for the correct Provider, users will need to enter your provider code. (the first panel of the TeamDrive Client can be suppressed using an OEM TeamDrive Client; please contact TeamDrive Systems for additional information)



A username, an email address, and a password is required to create an account. As described in enable-web-login=true/false/default (default: false), you can disable this dialogue and prevent the user from creating a new account using the TeamDrive Client.

Each new account must be activated by an email as described in Email Templates.

Login to an existing account

If the users already has an account, they can just login and register without typing in the Provider code:



If you enable the setting “allow-email-login” as described in allow-email-login=true/false (default: false) you can also login with an email. If more than one account with that email exists, a list of account usernames and emails will be displayed:


Forgotten password

In case of an unknown* or lost password, the user can set a new password. A temporary password will be send to the users email (as listed on the Registration Server). This temporary password is then entered along with a new password to complete the process.

*This can happen if a user import was performed, as described in the Administrative Guide.


Check activation


In order to finish the account creation process, the user needs to click on a link in the activation email (see mail templates in Templates for Client actions). This behaviour can be modified by the settings described in Client Settings)

Get activation email

The user can click the resend button to resend the activation email.

Undo registration

If the user quits the registration process, the device (see Device) of the user will be removed.

Retrieve user information

During the registration process the user’s data and license will be loaded into the client from the Registration Server in the background. Once users has logged in the email will be retrieved from the Registration Server so it can be displayed in the client. If the user does not have a default license, a new default license will be created for the user depending on the Provider settings (see DEFAULT_FREE_FEATURE (<FreeClientDefaultLicense> tag)).

Retrieve default storage account on a Hosting Service

This request will ask the Registration Server for a default storage account. Whether a default storage account can be retrieved for this user depends on the Provider settings see (AutoDistributeDepot). The created account will be stored on the Registration Server, so that the user will get the same storage account again, if they install a second device.


Each user not only has a user account, but each installation will also create a new owned device on the Registration Server under this user account. The user can install 5 different device types: Mac, Windows, Linux, iOS and Android OS (the amount of devices per user is not limited).

Each device will create its own public-/private key. The public key will be uploaded to the Registration Server for this device. If one users invites another, they will not actually invite the user itself, instead they will invite all the different devices of the target user. This is necessary because each invitation must be encrypted using the public key of the target device.


The client will periodically poll the Registration Server for new messages, like invitations. The different types of messages are described in TeamDrive Client <–> Server interaction.

Get public key

If a public key for a device is missing, it will be downloaded from the Registration Server and will be stored in the local key store of the client (filename PBPG.Keys in the client user data). In case of another invitation to the same device, the public key from the key store will be used. The keys will be stored under the device id in combination with the Registration Server name, because two different Registration Servers can hold devices with the same id’s.

Get device id

Invitations sent will always start with the oldest device of the user. Only active devices from a user can be invited. An active device is defined by the value <InviteOldDevicesPeriodActive> as described in Registration Server Settings.

Messages, Invitations & Invitation Types

All communication between clients is done by sending encrypted messages to the Registration Server which are then retrieved when the server is polled by the receiving client. A message could be an invitation, but other messages types exist and will be described in the following chapters.

Normal invitation

A normal invitation is an invitation to a TeamDrive Space. For further security, invitations can be password protected, requiring the receiving user to enter a password specified by the sender.

Store forward invitation

New users can be invited to Spaces using a “store forward“-invitation. In this case the invitation can not be encrypted using the Public-Key of the target device, because it doesn’t exists at this time. Instead, the invitation will be encrypted using the Public-Key of the Registration Server. If a new user creates an account using the same email address used for the invitation, the background task (see “Move Store Forward Messages”-Task) will then encrypt the lurking invitation using the Public-Key of the new created device. The new client then retrieves the invitation within the normal poll request interval.

Invitation for future devices

This functionality was added to resolve the following commonly occurring situation:

User A installs TeamDrive in his office, creates a few Spaces and fill them with data. At home he installs TeamDrive on his private PC and expects that he will be able retrieve the data in the Spaces he created in the office.

However, this is not the case because invitations can only be send to devices with an available public key. Before a device is registered, no public key is available.

User A will need to return to the office, start TeamDrive, and invite himself to all of his Spaces so that his private PC receives and invitation.

To solve this problem, a special invitation is sent for future devices of the user.

To keep this invitation secure, a SHA256 key is generated using the password of the user which is used to encrypt the invitation. Then the encrypted invitation is encrypted again using the Public Key of the Registration Server before being sent.

If the user installs a second device, he will receive this special invitation. The invitation is decrypted using the SHA256 key generated with the users password, allowing the user to access their space with their new device.


This will not work if the user changes his password after the first installation since the client will no longer be able to generate the same SHA256 key that was used to encrypt the invitation.

Future device invitations will be automatically deleted after a specified period of time in seconds. If you set the value to 0 these invitations will never be deleted.

Revoke invitations

An invitation can be revoked by a client. Because all invitations are encrypted and we can not see which invitation might be revoked if the device has more than one invitations stored on the Registration Server, we generate a hash over the Space information. A revoke will remove all invitations which match the hash.


his is only working, if the invitation was not already downloaded by the other client. If that’s the case, the user can use the following delete message.

Delete message

Sending a delete message to a user will remove all of their clients for the Space.


Invitation email

If an invitation was successfully uploaded to all devices of the invited user, the client will also send an invitation mail. The text for the invitation mail can be modified within the invitation dialogue. It will be send to the Registration Server which will mix the user data with the template of the right Provider and language. The mail templates are described in Email Templates.

Notification email

The user can send a notification mail to the member(s) of a Space to inform them about changes.

Change User data

Change password

The user can change their password within the client application (client version required and Registration Server version 3.0.9 required). The current and a new password must be typed in by the user. The new password will be set for all of the user’s client installations. Therefore, other installations will prompt the user for their new password with “password has changed” window.


Change email

The user can change their registration email in a two-step process.

  1. The user enters their new email address and clicks the Change button. This well sent an activation email to the new address.
  2. The users clicks the confirmation link with the activation email.

The new email will be changed across all of the user’s client installations.


License key

The user can change the license key by manually type in a new key. The key will be changed across all of the user’s client installations.


The client can be informed about new versions. The user will be informed about an update with a release description. A click on the update button will open a web page where the new version can be downloaded. This is only available for windows, mac and linux. iOS and Android must be informed about the market place functionality. Updates can be administered from the admin console (see Administrative Guide).

Server URLs

The client will poll in intervals for a new set of URLs. This will not only update the URLs of the own Registration Server, but will also get new informations about all available Registration Server within the TDNS network as described in “Update RegServer-List”-Task

Initial Storage Account Request

Unlike the above listed interactions, this request involves both a Registration and a Hosting server.

  1. During the registration process the client will ask the Registration Server for a default storage account.
  2. The Registration Server will look in his internal database, and check if this user already has a default storage account. If yes, it will be returned. If not, step 3 will be executed.
  3. The Registration Server will lookup to which Provider the user belongs and will look for a Hosting Service which belongs to this Provider. A depot creation request for this user will be send to the Hosting Service. The returned value will be stored in the internal database and the result will be also send back to the client.
  4. The client is now able to create Spaces on the Hosting Service.