TeamDrive Client-Server Interaction¶
Create a new user¶
A user can use the standard TeamDrive client to register a new user. To ensure that the user is created 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 when using an OEM TeamDrive Client; please contact TeamDrive Systems for additional information)
A username, an email address, and a password is required to register a user. As described in enable-web-login=true/false/default (default: false), you can disable this dialogue and prevent the user from registering a new user using the TeamDrive client.
Each new user must be activated by an email as described in Email Templates.
Login as an existing user¶
If users are already registered, they can just login 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 user with
that email exists, you have to select the right user. Click on the
and a list of usernames and emails will be displayed:
In case of an unknown* or lost password, the user can set a new password by requesting a temporary pin first. This temporary pin will be sent to the user’s email address (as listed on the Registration Server). This temporary pin 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 Users via CSV Files in the Administration Guide.
The user has to fill in his username to recieve the temporary pin.
The temporary pin together with the new password must be entered to updated the password on the server.
In order to finish the registration 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.
If the user aborts the registration process, the device (see Devices) 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).
Each TeamDrive Client installation creates a new device on the Registration Server associated with the user. The user can install clients on 5 different platforms: Mac, Windows, Linux, iOS and Android OS (the number of devices per user is not limited).
Each device will create its own public-/private key. The public key is uploaded to the Registration Server for the device. When a user invites another user, a message is sent to each of the target user’s devices. Each invitation is 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 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
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.
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.
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.
Invitations, will be deleted after a definable period of time, which can be
configured in the Registration Server Setting
Existing users can send out Space invitations to users that are not registered 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 registers 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.
Like normal invitations, store-forward invitations will be deleted after the
time period in the Registration Server Setting
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.
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.
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.
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.
Sending a delete message to a user will remove all of their clients for the Space.
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.
The user can send a notification mail to the member(s) of a Space to inform them about changes.
Change User data¶
The user can change their password within the client application.
Reset Password link on the users profile screen to get
to the password change dialogue.
Reset Password to recieve an email with a temporary pin.
Enter the pin from the email in the temporary password field together
with a new password and click on
Save. 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.
The user can change their registration email in a two-step process.
1. Go to the users profile and click on the email address to change it to a new one. Leave the email field by clicking somewhere outside the field. This well sent an activation email to the new address and a confirmation to the old address that a new address was entered.
- The users clicks the confirmation link with the activation email.
The new email will be changed across all of the user’s client installations.
The user can change the license key by manually typing 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 (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).
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.
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