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 users already have an account, they can just login and register without entering 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 by providing an email address. If more than one account with
that address 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 by requesting a temporary password first. A temporary password will be sent to the user’s email address (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 chapter Importing User Accounts via CSV Files in the the Administration 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 aborts 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 the user has logged in, the user’s details (e.g. email address) will be retrieved from the Registration Server so they 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).
Retrieve default space depot on a Hosting Service¶
This request will ask the Registration Server for a default Space Depot. Whether a default Space Depot can be retrieved for this user depends on the Provider settings see (AUTO_DISTRIBUTE_DEPOT).
The created account will be stored on the Registration Server, so that the user will get the same Space Depot again, if they install a second device.
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.
Invitations¶
The client will periodically poll the Registration Server for new messages, like invitations. The different types of messages are described in Messages, Invitations & Invitation Types.
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
time (in seconds) stored in setting InviteOldDevicesPeriodActive
as
described in
InviteOldDevicesPeriodActive.
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 improved security, invitations can be password protected, requiring the receiving user to enter a password specified by the sender.
Note
Invitations, will be deleted after a definable period of time, which can be
configured in the Registration Server Setting InvitationStoragePeriod
.
See InvitationStoragePeriod
Store-forward invitation¶
Existing users can send out Space invitations to users that do not actually have an account on this Registration Server yet, by using a “store-forward“-invitation.
In this case the invitations can not be encrypted using the public key of the target device, because it doesn’t exist 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 Registration Server will then decrypt the message with its private key and re-encrypt the pending invitation using the public key of the newly created device. The new Client then retrieves the invitation within the normal poll request interval.
Note
Like normal invitations, store-forward invitations will be deleted after the
time period in the Registration Server Setting InvitationStoragePeriod
has been reached.
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 sent 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 was sent in earlier registration server versions for future devices of the user. The future device invitation functionality is now replaced by using the key repository.
Each user will create an “user secret” derived from his password. A global public / private key will be generated during the first registration which is then encrypted with the “user secret”. For each new space a space key will be created and then encrypted using the generated global user public key. On a second installed device all space keys will be retrieved from the key repository and the space keys will be decrypted using the global private key of the user. For decrypting the global private key the users password will be used again.
Note
The users global public / private key will only be used for accessing the key repository. The client itself is using a separate public / private key for sending invitations to clients of other users. Accessing the users global public / private key will not work if the user change his password after the first installation since the client will no longer be able to decrypt the global public / private key. The user should change the password on his first installation. This will re-encrypt the global public / private key based on the new password.
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.
Note
This only works, if the invitation has not been 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.
Emails¶
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 3.0.5.155
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.
- The user enters their new email address and clicks the Change button. This well sent an activation email to the new address.
- 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.
Banner¶
Banner are only supported by TeamDrive 3.
The client will compare the locally stored banner with the data on the Registration Server. If the server has new banners available, they will be downloaded and replace the old banner. They will be visible after the client is restarted.
Updates¶
The client can be informed about new versions. The user will be informed about an update with a release description (only in version 3; version 4 will just inform the user about a new version without showing release informations). 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 Space Depot Request¶
Unlike the above listed interactions, this request involves both a Registration and a Hosting server.
- During the registration process the client will ask the Registration Server for a default space depot.
- The Registration Server will look in his internal database, and check if this user already has a default space depot. If yes, it will be returned. If not, step 3 will be executed.
- 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.
- The client is now able to create Spaces on the Hosting Service.
Note
The same functionality will also be offered using the API. Please enable creating a default depot for API request as described in API_CREATE_DEFAULT_DEPOT