Release Notes - Version 4.5

4.5.5 (2020-01-27)

  • Fixed the collation sequence on the TD2APIRequests.User column (REGSERVER-1592).

  • Admin Console: Only Host Servers that are owned by an account must be excluded from the list when creating a depot (REGSERVER-1589).

  • Added REDIRECT_FUSE provider setting. The FUSE page should provide information about downloading and installing FUSE, which is used by the TeamDrive client to create a virtual drive for spaces (REGSERVER-1587).

    Added the “redirect-fuse” HTML template which is returned by default when the FUSE redirect is requested by the client, if REDIRECT_FUSE has not been set to a specific URL. In general, if an HTML template exists for a redirect, then it will be returned if the corresponding setting is empty. The search arguments on the URL are available as template variables.

    Added the [[GETURL:<url>]] template function which is substituted for the contents of the specified URL, for example: [[GETURL:https://text.teamdrive.com/embedded-text.txt]]. Template variable substitution is also performed on the retrieved text.

  • Added new template conditional functionality. You can now compare a template variable to a specific value, using [[IF:<name>=<value>]], [[IFNOT:<name>=<value>]] and [[ELSEIF:<name>=<value>]], for example:

    [[IF:PLATFORM=win]]
    Platform: Windows!<br>
    [[ELSEIF:PLATFORM=mac]]
    Platform: MacOS!<br>
    [[ELSEIF:PLATFORM]]
    Unknown Platform: [[PLATFORM]]!<br>
    [[ELSE:PLATFORM]]
    No platform specified!<br>
    [[ENDIF:PLATFORM]]
    

    As before, if =value is not specified, then IF checks that the variable is not empty, and IFNOT, is true if the variable is empty.

  • Admin Console: fixed a bug that caused confusing messages when devices were deleted (REGSERVER-1582).

  • In the Admin Console it is now possible to switch a user to and from external authentication, as long as the super PIN is not enabled. Ensure that the user has a backup of their space keys, or has access to a TeamDrive client installation before making this change (REGSERVER-1556).

    It is also possible to enable and disable the super PIN for a user account, and to enabled and disable the user’s Key Repository. Enable and disabling encryption on a user device is also possible. Note that TeamDrive client version 4.6.12 or later is required to support this functionality.

  • Providers can now be removed when associated host servers are no longer accessable (REGSERVER-1555). When removing the provider, the depots are marked to be removed from the host server. A new auto-task: “Delete Depots on Host” will remove the marked depots from the host server in the background.

    If an error occurs when removing a depot, the error will be ignored if the host server of the depot has already been removed, or was never registered.

    In addition it is now possible to remove a host server in the Admin Console, even when the server still has existing depots. When removing a host server you can decide if you want to also delete the depots on the host server. If not, the reference to the depot will simply be removed from the Registration Server database.

  • Fixed “Table ‘td2reg.TD2AccountMember’ doesn’t exist” error when upgrading from version 3.5.5 (REGSERVER-1579).

  • The “activateuser” call now activates the user and all devices that have not been activated (REGSERVER-1574). See activateuser for details of all changes to the call.

  • Admin Console: changing a user’s email address, now requires confirmation from the user, who must click on an activation link send by email to the new email address (REGSERVER-1561). In addition, a notification is sent to the old email address that a change of email is in progress. If the email change is not confirmed within 2 hours the change is cancelled.

  • The Email Queue is now prioritized. Notification emails send by the TeamDrive client are considered low priority, and will only be sent after all other emails have been sent (REGSERVER-1570). This is to ensure that regular emails are sent despite limits to the email send rate.

  • Renamed setting SendGridIPList to EmailHookIPList. Added EmailHookURL.

  • Updated default HTML templates to look better on small screens.

  • Added DEFAULT_AUTH_SERVICE_NAME provider setting. If the provider is using an external authentication service that has not been upgraded, and therefore does not return it’s external authentication service name (see DEFAULT_AUTH_SERVICE_NAME).

  • Certain errors when sending emails not result in the email “bounced” flag being set (REGSERVER-1567). This includes, the following error codes, in combination with the text strings in the error messages:

    550, "invalid dns"
    550, "mailbox unavailable"
    550, "user unknown"
    

    If this the “bounced” flag is set, then emails will no longer be sent to the user.

    In the Admin Console a button is provided next to the “bounced” flag’s checkbox to display the Email Log for the user. This includes any email error events that may have occurred during the email send process.

    A further button, “Send Test Email” is provided, which sends an email to the user with a link in which the user can confirm the validity of their email address. For this purpose the email template confirm-email and the HTML template email-confirmed have been added.

    When the user clicks on the link, the “bounced” flags is removed from the user’s account, and all emails that failed to be sent are reset, and the Registration Server will attempt to send these emails again.

  • The portal registration page was incorrectly placing the email address in the username field after an error occurred (REGSERVER-1585).

4.5.4 (2020-10-20)

  • The setting RedirectorProtocol, now applies to all URL’s returned by the Registration Server. This includes the portal pages, and the provider “REDIRECT” settings, and global “RedirectURL” settings (REGSERVER-1575).

    Even if a setting such as REDIRECT_FAQ is set to a URL like: http://my.server.org/faq.html, if RedirectorProtocol is set to “https”, then then a request for REDIRECT_FAQ will return https://my.server.org/faq.html.

  • The “tdnslookup” API call new returns the Registration Server URL whenever it is returned by TDNS (REGSERVER-1565). In addition, the request tags <email>, and <lookupboth> have been added. See tdnslookup for details.

  • Removed the deprecated paths from the URL’s used by the Registration Server and Host Server. This affects the values of the following global settings: RegServerURL, MasterServerURL, LoadBalancerURL, PingURL and RegServerAPIURL, and possibly also some of the provider settings which contain URL’s (REGSERVER-1550).

    The URL’s were modified by changing the path components: “pbas/p1_as”, “pbas/td2as” and “pbas/td2api” to “yvva”.

    In addition, the ”.htm” extension for API access is deprecated, and ”.xml” should be used.

    As now specified in API Basics, the URL to access the the Registration Server’s API is as follows:

    https://<domain>/yvva/api/api.xml?checksum=<md5>
    
  • Fixed error in the “createdepot” API which caused it to incorrectly return the error: “Cannot create depot, not permitted by license” (REGSERVER-1549).

  • Minor email template improvements (REGSERVER-1544).

  • Added redirect URL to the Web Portal (REGSERVER-1546). Using the ”.json” extension on the request will result in a JSON result, which contains the re-direct URL, for example:

    {
      "distributor":"PAL3",
      "language":"en",
      "language-arg":"en-GB,en-US;q=0.9,en;q=0.8",
      "page":"webportal",
      "resulttype":"ok",
      "url":"http://localhost:33000?dist=PAL3"
    }
    

    If an error occurs then the “resulttype” field is set to “exception”:

    {
      "distributor":"EXT1",
      "errorcode":-30147,
      "errormessage":"No URL provided for requested page",
      "language":"en",
      "language-arg":"en-GB,en-US;q=0.9,en;q=0.8",
      "page":"webportal",
      "resulttype":"exception",
      "secondarycode":0,
      "test":"false"
    }
    

    If the request includes “test=true”, then the Registration Server will attempt access the URL, and report an error if it fails:

    {
      "distributor":"PAL3",
      "errorcode":-12171,
      "errormessage":"Failed to connect to localhost port 33000: Connection refused",
      "language":"en",
      "language-arg":"en-GB,en-US;q=0.9,en;q=0.8",
      "page":"webportal",
      "resulttype":"exception",
      "secondarycode":7,
      "test":"true",
      "url":"http://localhost:33000?dist=PAL3"
    }
    
  • All API functions that send emails now also accept a fields list, which is used to set custom template variables, for example:

    <fields>
      <os>iOS</os>
      <contact-person>Joe Smith</contact-person>
      <description>This is a test...</description>
    </fields>
    

    This input will set the template variables as follows:

    • [[OS]] = “iOS”
    • [[CONTACT-PERSON]] = “Joe Smith”
    • [[DESCRIPTION]] = “This is a test...”

    Template variables set using the <fields> tag may may not overwrite default values used by the Registration Server. A warning will be logged if you attempt to do this.

  • Added new auto-task: “Synchronise TDNS” (REGSERVER-1554). This task verifies the TDNS entry for all users. If the entry exists, but is owned by another Registration Server or Provider, then it sets a flag on the user, which is indicated by the test “No TDNS Entry” in the Admin Console.

    If TDNS cannot be updated when a user is created, this task performs the update later. These user’s will be marked as “TDNS Update Pending” in the Admin Console. Note that only TDNS updates can be delayed, if adding the TDNS entry fails, then user creation will fail.

4.5.3 (2020-07-22)

  • The Host Server of an account can now be specified to be owned by the account (REGSERVER-1532). In this case, managers of the account are automatically granted CREATE-DEPOT, EDIT-DEPOT-COST and DELETE-DEPOT rights to depots using the Host Server.

    Note that if a Host Server is not owned by the account, then it is no longer possible for a manager to set the size of the default depot.

    Specifying a Host Server for an account, without granting ownership means that the Host Server is just used to create the default depots of the users of that account.

  • In the Admin Console, the Depot list now includes depots owned and in-use by account members. As a result, an account manager may not have access to all the depots listed because account managers only have access to the following depots:

    • Depots owned by the account
    • Depots that belong to the Host Server that is owned by the account

    Note that you also only have access to the history of a depot, if you have full access to the Host Server of the depot.

  • Resetting the number of incorrect login attempts on the Admin Console did not apply to the Admin Console itself (REGSERVER-1533).

  • The Admin Console now supports external authentication (REGSERVER-1530).

    In addition, you can login to the Admin Console using your email address as as user or provider (REGSERVER-1537). If an email is in use by both a provider and a user, then you will be required to select the required user from a drop-down list.

  • It is now possible to create a user that uses external authentication on the Admin Console. In order to do this, the user’s email must be associated with a external authentication service, or setting AUTH_LOGIN_URL and VERIFY_AUTH_TOKEN_URL must be set for the provider.

    Note that USE_AUTH_SERVICE must also be set to True in all cases.

    User’s created on the Admin Console that use external authentication will have no “External Authentication ID”. This value will be set the first time the user actually logs in (either using the Admin Console or the TeamDrive client or a Web Portal).

  • If a user is using an named external authentication service, then this will be indicated in the Admin Console. Alternatively the user may now be explicitly marked as using an external authentication service or not. This is the case with all users created on the Admin Console.

    As before, for all other user’s the standard authentication is the default, even if USE_AUTH_SERVICE is set to True and AUTH_LOGIN_URL and VERIFY_AUTH_TOKEN_URL values are provided. To ensure users of the provider use external authentication, PRE_LOGIN_SETTINGS must include (at least) the enable-login=false and enable-web-login=true, client settings.

    However, if a user is explicitly marked as either using an external authentication service or not it is not necessary to set the PRE_LOGIN_SETTINGS for the user. The Registration Server will automatically set the pre-login settings as required.

    In this case, the settings will override any settings that have been set using PRE_LOGIN_SETTINGS at the provider level. So, for example, it is possible to have one user use standard login while all other users of a provider as using external authentication.

  • On the Admin Console you can change the authentication method of a user from external authentication to standard (Registration Server-based) authentication and back, provider the user has no devices, and no space keys in the key repository (REGSERVER-1529).

    If a user is changed to standard authentication then the user will also be de-activated, and an email sent to the user which provides a link to a page where the user can set a password for their account.

  • Moved ALLOW_WEB_PORTAL_ACCESS setting to the WEBPORTAL settings group and moved REG_NAME_COMPLEXITY to the LOGIN settings group.

  • Added “inbox-confirm-upload” and “inbox-upload-notification” email templates user by the inbox agent to notify users after files are uploaded to an inbox (REGSERVER-1538).

    The setting MaxInboxEmailPerDay has been added to limit the number of emails sent by an inbox user. This setting is used instead of the MaxInboxEmailPerDay setting used by regular users (see MaxInboxEmailPerDay for details).

4.5.2 (2020-06-25)

  • Accounts now include a Super PIN Repository, which stores the Super PINs of all members of the account. To enable the Super PIN Repository the manager must create a “master password” which is then associated with the repository.

    When enabled, users will be prompted to login in order to upload their Recovery Data to the repository. After this point, if a user looses their password, a manager can send the user a Recovery Code, via email, by entering the master password.

    The user can then login using the Recovery Code as a once-off password. The Recovery Code is only valid for a limited time.

    Managers can also request that users of the account enable the Super PIN functionality. Users will then be prompted to login in order to enable the Super PIN.

    Note that the Super PIN functionality will be enabled automatically when using the Web Portal, or when local encryption is enabled (which requires allow-local-encryption=true).

    These functions require TeamDrive client version 4.6.9 or later.

  • Added EnableSuperPINRepository Registration Server setting. If False (the default) the option to enable the Super PIN Repository, and the function to require account users enable the Super PIN are not available in the Admin Console.

  • Set the new setting ACCOUNT_RESTRICTIONS to super-pin-repo-pro-license-limit=5 to restrict the use of the Super PIN Repository feature to accounts with 5 or more professional licenses (REGSERVER-1490).

    This means that accounts with less professional license will not be able to enable the Super PIN Repository. By default, this Super PIN Repository is not restricted.

  • Added support for SendGrid notifications (sendgrid.com). In order to receive notifications you must set the Registration Server setting SendGridIPList to a list of IP addresses that are the source of the notifications (REGSERVER-1517).

    The Registration Server will forward notifications to other Registration Servers if necessary (based in a TDNS lookup of the email address). This is done by the “Forward SendGrid Events” Auto Task. The IP address of forwarding Registration Servers must also by included in the SendGridIPList list.

    The “email bounced” flag will be set for user’s with email address on which an error notification occurs. Emails are no longer sent to these addresses, and are marked in the email send queue as such. The errors on an email address can be cleared by removing the “email bounced” flag for the user in the Admin Console. When this is done, the Registration Server will attempt to send (retry) all outstanding emails to the user.

  • The “Send Emails” auto task will now no longer attempt to send an email to a user who has the “email bounced” flag set. Instead the email will be marked with status “Bounced”. Emails will also not be sent to email address that have a error registered in the Email Error log (which is written by SendGrid notifications).

    Resetting the email status will remove both the “email bounced” flag as well as the errors in the Email Error log, to ensure that the Registration Server really attempts to send the email.

  • An account can now be set for a domain (REGSERVER-1522). If the domain is active then any user created with an email using the domain will automatically be added as a member of the account, and use the default license as specified by the account.

    This also applies to users that are automatically created due to an invitation. Note that such users will not be removed by the “Remove Auto Created Users” auto task (even if not activated), since they are members of an account.

    An error occurs if a new user is created for an account, with an email address that is reserved for another account. However, it is possible to move a user with a reserved email address to another account.

  • Users that are created due to an invitation will only be displayed as guests of an account if they belong to the same provider (REGSERVER-1528).

  • On login using a registered external authentication service, the Registration Server incorrectly required the VERIFY_AUTH_TOKEN_URL setting to be set, instead of using the Verify URL specified for the service (REGSERVER-1531).

Administration Console

  • Combined the HTML and Email templates pages into one page called “Manage Templates”.

  • When sections are opened on the Edit Account page, they remain open after page reload.

  • Resetting the status of an email in the email queue will cause all errors recorded for the email to be deleted, and the user’s “email bounced” flag will also be set. This is to ensure that the Registration Server really tries to resend the email.

    If you wish to retry sending all emails to a particular email address, then go to the user of the email, and reset the “email bounced” flag.

4.5.1 (2020-05-12)

The most significant additions to the Registration Server in this version are the “Super PIN” functionality, and support for a new “on-boarding” process.

The Super PIN functionality is required to support client-side “local encryption”. The Super PIN is activated for a user account when client-side local encryption is enabled by the TeamDrive client.

Local encryption adds an addition layer of security by protecting important data stored on then client. When using a Web Portal, local encryption is automatically enabled.

When the Super PIN is activated, the user may no longer set their password using a temporary password. If the user forgets their password they must either enter their Super PIN, or a Recovery Code, which is obtained using a “Recovery URL” (stored as a QR Code).

The user will be promoted by the TeamDrive client to export and store this information when the Super PIN functionality is enabled.

It is now possible for a provider to reserve domains and register external authentication services. Reserved domains must be activated by TeamDrive before they are used. When activated, domain reservation, prevents users of other providers from using email addresses with the reserved domains. In addition, external authentication services can be registered and then associated a reserved domain.

This information used by the TeamDrive client to locate the correction Registration Server during login and registration (required client 4.6.9), and the domain-based external authentication selection service.

Domain and service information is stored on TDNS (the TeamDrive Name Service), and can be managed using the Registration Admin Console.

The new on-boarding process involves the automatic creation of user accounts when a user is invited to a space (see the new INVITATION_CREATES_USER provider setting). The user is registered using the email specified in the invitation, and does not have a username (which means that USER_IDENTIFICATION_METHOD must be set to email or default, see USER_IDENTIFICATION_METHOD). An email (the reg-activationsetpassword email template) is sent to the user with a link which allows the user to set a password for their user account. Activation is optional (see ACTIVATE_ON_INVITATION).

Note: if the user is not activated within a certain number of days, specified by AUTO_CREATED_USER_TIMEOUT, then the user will be automatically deleted. By default this is 60 days (see AUTO_CREATED_USER_TIMEOUT for details).

Users added by invitation, are listed as “guests” members of an account, if they are invited by a member of an account (REGSERVER-1504). Guest users can then be easily added to the account as member or manager.

After setting a password, the user may be provided with links to a Web Portal, or with a link to download the TeamDrive client. This can be done by configuring the relavent HTML templates, in particular set-password-ok. After login, using email and password the user will have access to the space to which they were invited.

On-boarding in this manner is the default when a user is created in the Admin Console. In other words, after creating a user in the Admin Console the user is sent an email with a link that allows the user to set their password, and after doing this proceed to a Web Portal or to download the TeamDrive client.

Users that are on-boarded automatically using this functionality can be granted a special license as specified by the NEW_USER_LICENSE_FEATURES provider setting.

In addition to these changes, it is now possible for a manager to invite an existing users to an account. Support is provided for this in the Registration Server API and the Admin Console. Invited users can be assigned a license which will be applied when the user accepts the invitation. Licenses assigned during invitation are counted to the usage of those license.

Registration Server Functionality

  • Added support for registration of users without a username in the TeamDrice client.

  • The [[SUPERPIN]] conditional template variable is now used in the new-passwd and web-newpassword templates to return an appropriate message to users that attempt to change their password using an old TeamDrive client, after the Super PIN has been activated (REGSERVER-1447).

    Conditional blocks in templates may now have the form [[IF:<cond-var>]] ... [[ELSE:<cond-var>]] ... [[ENDIF:<cond-var>]] (the ELSE markup tag is optional).

  • Added SUPERPIN_LOGIN_WITHOUT_ACTIVATION setting which determines whether an activation email is sent the user when using a Super PIN to login to a new installation (REGSERVER-1451).

  • Added TEMP_PASSWORD_TIMEOUT provider setting which determines the amount of time a temporary password valid (REGSERVER-1438). Default is 10 minutes.

  • Added the MAXIMUM_DEVICES_PER_USER provider setting. The default value is zero, which means no limit. If set to another value the new “Deactivate/Activate Devices” auto task will enabled and disable devices as required to ensure that only the specified number of devices are active. The disabled devices are set to the “too many devices” status (REGSERVER-1399).

    The server always disables the least recently used devices. As a result, a device can be reenabled by simply running the TeamDrive client. However, it takes an average of 3 hours before a device is reenabled by the server.

    The device status is now sent to the TeamDrive client which should disable the GUI and stop synchronisation when the status of the devide is disabled.

    In this state the device will receive invitations, but will not send them to the client. This ensures that if the device is enabled, then the invitations will be sent to the client.

  • Added new provider settings: INVITATION_CREATES_USER, INVITATION_NEW_USER_PROVIDER, NEW_USER_LICENSE_FEATURES and ACTIVATE_ON_INVITATION (see INVITATION Settings).

    These new settings belong to the INVITATION settings group, which was previously called the REFERRAL group.

  • A new email template, inv-newuser-invited, has been added (see Templates for Client Actions). This template is used when a user is automatically registered by the new INVITATION_CREATES_USER feature (see above).

  • A [[DISCLAIMER]] email template field has been added to all email templates to which it may apply (REGSERVER-1290). The disclaimer text can be set in the Admin Console under the account of the user. If no disclaimer text is available, then the [[DISCLAIMER]] field is removed, including the extra empty line that results from this.

  • When the TeamDrive client requests the “default” depot, the Registration Server will now return any depot that the user has in use, if the user’s “cloud depot” and default depot’s do not exist.

  • Added the NoDepot license feature which disables the creation of a default depot for new users (see DEFAULT_FREE_FEATURE).

  • The server now retains the “default” depot status, when the default depot is removed from usage. As long as the user’s default depot is either in-use or is owned by the user, it retains the “default depot” status for the user.

    In addition, the default depot status will be restored to a depot, if it is removed from the user (both in-use and ownership), and then added again, as long as the user is not given a different default depot.

    As long as the user has a default depot, no new default depot will be created.

    In previous version of the server, removing the usage of a the default depot from a user would cause a new default depot to be created (assuming HAS_DEFAULT_DEPOT is set to True), as soon as a TeamDrive client calls the Registration Server.

  • The ALLOWED_DIST_CODES is now also applied on user registration. However, this is only done when the client sends the distributor code from the DISTRIBUTOR file (REGSERVER-1402). This required client version 4.6.8 or later.

    For login, clients before this version were not sending the distributor code from the DISTRIBUTOR file if users entered a different code in the Provider panel. In this case the server was checking the entered distributor code.

    In the case of external authentication all client version send the correct distributor code (the distributor code from the DISTRIBUTOR file).

  • Added a checkbox to accept the “Terms of Service” on the portal registration page (template: portal-register), and the set password activation page (template: set-password) (REGSERVER-1450).

    Added the REDIRECT_TERMS provider setting which specifies the “Terms of Service” page. A reference to this page is used in the portal-register and set-password HTML templates.

  • Added depot template: depot-warning, depot-cancelled, depot-reduction and depot-reduced which are used by the Host Server to inform the managers and owners when depots usage has exceeded the required limit (see :ref:mail_templates_for_depots).

  • The USE_SENDER_EMAIL setting has been deprecated, and replaced by FROM_EMAIL_OPTIONS (see FROM_EMAIL_OPTIONS). The FROM_EMAIL_OPTIONS value is set by default so that the behaviour of the Registration Server in this regard will not change (REGSERVER-1452).

  • Added the EnableDomainSupport (TDNS) setting. When set to True this setting enables the support for the reservation of domains and registration of service by a provider.

  • Added the PREVIOUSLY_UNNAMED_SERVICES (AUTHSERVICE) provider setting. This setting must be used when upgrading an existing external authentication service to a “named” service. “Named” services are services registered globally on TDNS (This is done using the Admin Console).

  • Changes to provider settings:

    • Renamed settings group: LOGIN to ADMINCONSOLE
    • Renamed settings group: ACTIVATION to LOGIN
    • Rename setting ALLOW_LOGIN_WITHOUT_EMAI to LOGIN_WITHOUT_ACTIVATION
    • The following setting have been moved from CLIENT to new LOGIN group: ALLOWED_DIST_CODES, PRE_LOGIN_SETTINGS, LOGIN_WITHOUT_ACTIVATION, ALLOW_NEW_REGISTRATION, ALLOW_MAGIC_USERNAMES, ALLOW_WEB_PORTAL_ACCESS, ALLOWED_LOGIN_ATTEMPTS, FAILED_LOGIN_TIMER, SUPERPIN_LOGIN_WITHOUT_ACTIVATION, TEMP_PASSWORD_TIMEOUT and USER_IDENTIFICATION_METHOD.
  • Documentation: updated screenshots in section Using the Administration Console

  • The email template: reg-registrationnotify, which was previously unused, is now sent after a user sets a password using the link sent in the activationsetpassword email. The [[PASSWORD-SET]] template variable is also set to true in this case.

  • Added global setting: EmailSendRate, which determines the maximum rate at which emails will be sent. The default is “0”, which means unlimited. Any other value is the number of emails that may be sent per minute.

  • Added the SPACE_SIZE_LIMIT provider setting which restricts the size of spaces for users with a restricted or non-professional license (REGSERVER-1502).

  • Fixed TD2OwnerMetaHistory does not exist error when updating from Registration Server 4.0.1 (REGSERVER-1520).

Registration Server API

  • The “registeruser” API call now supports the option <nodepot> which, when set to true, prevents the assignment, or creation of a default depot for the user. In addition, a depot may be assigned to a user on registration using the appropriate tags (REGSERVER-1326).

  • The new “inviteusertoaccount” API call can be used to invite a user to an account via email. The call will send the “account-manager-invitation” or “account-member-invitation” email template depending on the type of invitation. The user is provided with links in the email to either accept or reject the invitation (REGSERVER-1289).

    The function to invite users to an account is also available in the Admin Console.

  • The “tdnslookup” API call will now work, even when the Registration Server is not connected to TDNS. In this case the call will return information from the local database (REGSERVER-1410).

  • Added a <messagetext> tag to the “registeruser” API call. This tag specifies a message that can be placed in the email sent by the call use the [[MESSAGE-TEXT]] template variable.

    Also added a <sendcc> tag (default is false). When set to true the Registration Server will “CC” the email sent to the user, to the caller (set by the <changeuser> tag).

  • All email addresses must now have the form: x@x.x, where x is one or more characters. White space, ‘,’ and ‘;’ are not allowed (REGSERVER-1471).

  • Added “getsettings” API call. A list of Registration Server and provider settings can be specified, using the <settings> tag. This tag is also supported by the “getuserdata” and “getaccountdata” API calls (REGSERVER-1511).

Administration Console

  • The Admin Console will indicate if the Super PIN functionality has been enabled, and also allows managers to disable the Super PIN functionality, which will delete the user’s Super PIN.

    Only delete the user’s Super PIN if the user has lost both their Super PIN and their password. After removal, the user may then set their password using the temporary password functionality, however previously local encrypted client installations will not be accessable, including Web Portal containers.

    In addition, the user will loose access to space keys stored in the Registration Server’s key repository.

  • It is now possible to specify a banner and a footer for the Web Portal user interface, for all users of an account, see Customize Web Portal under Extended Settings (REGSERVER-1433).

  • Host Servers can now be assigned to accounts (REGSERVER-1299). In this case, the account Host Server overrides the Host Server specified by the HOST_SERVER_NAME provider setting. In addition,account managers are able to set the following parameters at the account level:

    Default depot: Determine whether members of the account have a default depot. This setting, can override the provider level settings PROVIDER_DEPOT and HAS_DEFAULT_DEPOT.

    Storage size: This is the storage size of default depots created. This setting override the HOST_DEPOT_SIZE provider setting.

    Traffic limit: This sets the traffic limit of default depots created. This setting override the HOST_TRAFFIC_SIZE provider setting.

    See HOSTSERVER Settings for more details on these settings.

  • When creating a user, a checkbox has been added which allows you to prevent the creation or assignment of a default depot.

    Note that a default depot will nevertheless be created with the user’s first client registration, unless:

    • the user belongs to an account with a default account depot,
    • the user’s account has a host server and the Default depot account level setting to prevents the creation of a depot,
    • the user’s license has the NoDepot feature.
  • The “Purchase License/Depot” buttons now open a new browser page or tab (REGSERVER-1281).

  • UI improvement: the background of the paging control is now transparent.

  • The user’s account depot is now included in the user’s list of depots (REGSERVER-1419).

  • Added domain and external authentication service management. This is only enabled when the setting EnableDomainSupport to True (by default False). This functionality requires TDNS 1.9.11.

  • Depot lists now have separate columns for Storage/Traffic limit/used and can be individually sorted (REGSERVER-1472).

  • Added a new InboxUploadForm account-level setting, which can be used to configure a form that users must fill out before uploading files to an inbox

External Authentication

  • The domain-based selection of the external authentication service (domain directory) now uses the reserved domain information, and the associated authentication services to direct user’s to the correct external authentication service.

    The other external authentication services have been updated to check the configuration using the information stored centrally (TDNS 1.9.11).

    Check the example configuration files for information on the new settings, and changes you need to make to upgrade services.

Release Notes - Version 4.1

4.1.4 (2020-02-19)

  • Changed collation of all emails columns to case-insensitive (REGSERVER-1480).

    All input email are converted to lower-case: in import, and email addresses from external authentication services (REGSERVER-1479).

  • Fixed format of output on “Download Client Log Files” page. Long “words” are are now wrapped as required (REGSERVER-1481).

4.1.3 (2020-01-16)

  • Added the RedirectorProtocol server setting which can be used to specify the protocol of the “redirect URL” (REGSERVER-1473).

  • Fixed a problem that prevented update notifications to the TeamDrive clients from working (REGSERVER-1474).

    Added a new provider setting: UPDATE_TEST_VERSION which can be used to set the version to be used testing an update notification (see UPDATE_TEST_VERSION).

  • Admin Console: fixed problem with Provider Codes that consist only of digits (REGSERVER-1028). This caused various problems, for example, it was not possible to create an inbox.

  • Fixed a problem that caused the “Expire Licenses” auto-task to fail when a license belonging to an inbox user expired. The error generated was “The inbox user must have a license with the inbox feature” (REGSERVER-1466)

  • Fixed the “Lock wait timeout exceeded” errors, that occurred due to an UPDATE to the TD2Message that was performing a table scan (REGSERVER-1465).

  • Change required for compatible with yvva 1.5.2.

4.1.2 (2019-09-16)

  • Added documentation for web portal settings. The setting API_WEB_PORTAL_IP has been moved to the WEBPORTAL settings section.

  • Admin Console: the Manage Licenses page now includes the option to search for “Inbox” licenses (REGSERVER-1436).

  • Admin Console: the License Report page was not working due to an error when retrieving the report list from the database (REGSERVER-1444).

  • When moving spaces to another depot, it was possible to move a space to a depot to which the account manager did not have access (REGSERVER-1442).

  • Corrected email template usage when forcing re-login or reseting a user’s password. The email templates sent for these actions were reversed.

  • Admin Console: corrected “Force Re-Login/Invalidate Password” functionality in the case where USE_AUTH_SERVICE is set to True, but AUTH_LOGIN_URL remains blank. In the case, external authentication is not being used (since AUTH_LOGIN_URL is required for external authentication, instead the Registration Server Portal login pages have been activated.

    As a result, the “Force Re-Login” button should read “Invalidate Password” in this case. This is due to the fact that invalidating the user’s password has a different effect, depending on whether external authentication is being used or not.

    This will be changed in Registration Server 4.5, where only the “Force Re-Login” functionality will be provided, in both cases, i.e. whether external authentication is being used or not.

4.1.1 (2019-06-19)

  • Admin Console: fixed crash when logging in with email address, instead of username.

  • [account] in redirector URL will now be replaced with blank, if the user has no account.

  • CSV import results displayed on the “CSV User Imports” page in the Admin Console, can now be viewed in the browser rather than downloaded directly. A success and/or error file is only available for viewing if at least one success or failure occurred during the import (REGSERVER-1398).

  • In the Admin Console, the selection method used in dialogs has changed. If multi-select is allowed, then the checkbox are used to indicated which items have been selected. In the single selected case, radio buttons indicate which item has been selected.

    Currently adding members to an account and users to a license allow multi-select. A “Select All” button is also available in these cases. An extra dialog, confirming your selection is presented when adding more than 15 users (REGSERVER-1397/REGSERVER-1418).

    In addition, the paging section above search results has been improved to provide more options. You can now jump to the beginning or end of the result, and also move ahead or back a number of pages by clicking ”...” (which is only available when sufficient pages are available).

  • Since version 4.0 the Registration Server is compatible with PHP 7.2 / 7.3. However, the Admin Console may have problems after upgrading PHP due to the fact that the “mysql” extension has been removed from PHP 7 and later. Documentation has been added to help users solve this problem: Using version 4.0 with PHP 7.2 / 7.3.

  • Added Web Access to the account-level client settings. The default values of the account-level client settings are now determined by the provider setting CLIENT_SETTINGS value (REGSERVER-1401).

  • In the Admin Console, on the Depots page, you can now search for the depot owner’s email in addition to the owner’s username. The owners email address is also display in the list (REGSERVER-1411).

  • Added “web-user-deleted” email templated which is sent to the user after the user’s account has been deleted (REGSERVER-1405).

  • On login to the Admin Console the username is now case-insensitive (REGSERVER-1406).

  • Template names are now displayed in the Admin Consoles email queue (REGSERVER-1409).

  • An “inbox” type license can now be created in the Admin Console (REGSERVER-1414).

Registration Server API

  • Emails sent by the API may now include the following email template variables: [ORIGIN-$USERNAME], [ORIGIN-USERNAME], [ORIGIN-EMAIL] and [ORIGIN-USERNAME-AND-EMAIL]. These variable will be empty unless the <changeuser> tag has been set in the API call. The “web-activationsetpassword” template has been changed to include a reference to the originator of the email, if the <changeuser> tag is set (REGSERVER-1413).
  • Added an option to change a user’s account in the Admin Console (REGSERVER-1407). This function is supported by the addition of the <removemembership> tag to the “addusertoaccount” API call.
  • Added documentation for the “updateuser” API call (REGSERVER-1408).

4.1.0 (2019-04-18)

  • Fixed a error that prevented users from being removed, after the Provider was deleted. The problem occurred after the Provider was removed from TDNS (which is required in order to delete a Provider).
  • Added the provider setting required to connect the Registration Server to a web portal API. This API can now be used to create an inbox service for an account. The user which is hosting the inbox needs a license with the inbox feature.
  • Removed the banner management page in the Admin Console. The Banner administration of banners. This includes the Banner feature bit used by licenses. This feature is still displayed for licenses with this feature bit, but the feature can no longer be set.
  • The Personal license feature is no longer supported by version 4.1 of the Registration Server. This feature was only used by TeamDrive 3 clients. Users must now use the Professional license feature instead of the Personal license feature.
  • Changes to provider settings are now recording in a change history. The change history of provider settings can be viewed in the Admin Console.

Release Notes - Version 4.0

4.0.1 (2019-03-29)

  • [account] can now be used in the help redirect URL
  • Several bug fixes and improvements to version 4.0.0

4.0.0 (2018-09-19)

Registration Server Functionality

  • Removed the provider setting: HOST_SERVER_URL. This is no longer required, the Host Server to be used is specified by HOST_SERVER_NAME.

  • Added support for accounts (REGSERVER-1229). Accounts belong to a provider and include a number of users, groups, depots and licenses. An account is administered by a number of managers. A user can only belong to one account, but may be manager of a number of accounts. Accounts are explained in the the new chapter Account Concept and in a adminconsole chapter Accounts.

  • Added support for groups (REGSERVER-1196). Users can be invited to join a group, which is administrated by a Group Manager. The user receives an email, which contains a link for joining the group and another link for rejecting the invitation. Users that have rejected invitation 3 or more times can no longer be invited to a group.

    Users can only belong to one group, so when the join a group they are automatically removed from any other group.

    The Manager of a group can assign a license and a Host Server Depot to the group. The group license and the group Depot are used by all members of the group, and have priority over the user’s default license and Depot.

    Please notice that group functionality is not available in the 4.0 release of the Admin Console. This will be added in version 4.1.

  • The setting UserNameCaseInsensitive has been deprecated. All Registration Servers now use case-insensitive usernames. The TDNS entries will be automatically updated of your server had UserNameCaseInsensitive set to False.

  • The Registration Server now uses a new mechanism to synchronise the Depot usage with the Host Server and the TeamDrive Client. The mechanism ensures that changes to Depot usage on the Registration Server is always reflected in the Depot list in the TeamDrive Client, and in the Depot access list on the Host Server.

    Previously, it was possible that there were differences in the Depot configuration for a user between the TeamDrive Client, Registration Server and Host Server. This was due to a number of factors:

    • The Host Server access list for a Depot was previously not updated by the Registration Server API.
    • By setting <sendtoclient>false</sendtoclient> in an API call the user could previously specify that the changes to the Depot configuration of a user are not sent to the TeamDrive Client. This tag is now deprecated (see below).
    • If a TeamDrive Client device was not in use for a long time it was possible that changes to the Depot configuration were lost.
  • The following characters are never allowed in usernames: ‘$’, ‘;’, ‘,’, ‘@’ ‘”’ and the single quote (“’”).

  • When setting up a Registration Server, the server name is not allowed to contain a ”.”, or any spaces. The server domain must be valid, and contain at least one ”.”.

  • Added the DEFAULT_ACCOUNT_FEATURE provider setting which is identical to the LICENSE_FREE_FEATURE but applies to users that belong to an account (REGSERVER-1253). If DEFAULT_ACCOUNT_FEATURE is empty then the Admin Console will not allow managers to create a new license when adding a user.

  • Added the ACTIVE_SPACES_LIMIT provider setting which determines the maximum active spaces for users with a restricted license (REGSERVER-1257).

  • Improved security by defining a maximum login attempt and interval (see LoginMaxAttempts and ALLOWED_LOGIN_ATTEMPTS)

  • Added the PROVIDER_LOGIN_ID setting which is a list of IP addresses of users that may login with provider level or higher privileges (REGSERVER-1333). On upgrade this setting is set to the value of the LOGIN_IP value, if this value is not empty. Providers that wish to allow normal users or account managers to access the Admin Console from any IP address must set LOGIN_IP to empty.

  • License that expire are now also valid on the “Valid Until” date (REGSERVER-1389).

  • The Registration Server was sending an incorrect result to the client when a disabled user requested a temporary password (REGSERVER-1237).

  • Removed deprecated auto task: “Move Store Forward Messages”.

  • Fixed possible deadlock involving the Devices table and the “Delete Client IPs” auto task (REGSERVER-1464).

Registration Server API

  • The output parameter <number> in the searchuser API call, and the getlicensedata API call has been deprecated and will be removed in a future version. Use the license key number now returned in the <licensekey> tag.

  • The Host Server API URLs returned by the API will now begin with “https://”, if the provider setting API_USE_SSL_FOR_HOST is set to true.

  • Added “createdepot” API call.

  • Added API calls to support account functionality: “createaccount”, “deleteaccount”, “addusertoaccount”, “removeuserfromaccount”, “assignaccounttolicense”, “removeaccountfromlicense”, “setdepotaccount”, “removedepotaccount”, “setgroupaccount”, “removegroupaccount”, and “getaccountdata”.

  • Added API calls to support group functionality: “creategroup”, “deletegroup”, “inviteusertogroup”, “removeuserfromgroup”, “setgrouplicense”, “removegrouplicense”, “setgroupdepot”, “removegroupdepot”, “userjoinedgroup”, “setgroupclientsettings”, and “getgroupdata”.

  • A number of API calls now also return group related information: “loginuser”, “searchuser”, “getuserdata”, “getlicensedata”, “getdefaultdepotdata”.

    The “getuserdata” call now return account and group information by default. Set the input tags: <includeaccounts> and <includegroups> to false in order to exclude this information. This call also returns license currently assigned to the user in the <license> block in the <userdata> block. If <includegroups> is true then this is the group license if the user belongs to a group with a license.

    The calls: “loginuser” and “getlicensedata” return the user’s group information by default. Set the input tag: <includegroup> to false in order to exclude the group information.

    The calls “searchuser” and “getdefaultdepotdata” do not include group related data by default. In this case you must explicitly set <includegroup> to true to receive this information.

  • The <depot> block returned by the calls “getuserdata” and “getdefaultdepotdata” calls includes a number of new tags:

    • <globalid> is the global identifier of the depot.
    • <iscloud> is set to true if the depot is the user’s default cloud storage.
    • <isaccount> is set to true if the depot is set on the account level.
    • <isgroup> is set to true if the depot belongs to the user’s group.
  • When returning information about licenses (<license> tag) the <isgroup> tag is now included. This tag is set to true if the license belongs to the user’s group.

  • In the “registeruser” API call new supports a number of new tags: <accountkey>, <accountreference>, <groupreference>, <featurevalue>, <clientsettings>, <activate> and <sendmail> (see registeruser for details).

  • The <sendtoclient> tag is the API calls: “setdepotforuser” and “removedepotfromuser” is deprecated. If present, the tag is now ignored by the Registration Server. Changes to the usage of a Depot are now always sent to the TeamDrive Client.

  • Added API calls: “syncdepotdata” and “getdepotdata”.

  • API calls that send emails now support the <sendmail> tag. This allows the caller to override the API/API_SEND_EMAIL setting, to determine whether an email is sent or not.

  • The <changeuser> tag is used to specified the username of the user that is making changes to depots.

  • Added <setpassword> tag to the “registeruser” API call. When set to true (default is false), this will send an email using the web-activationsetpassword template to the user. This email contains a link to the set-password HTML template, which allows the user to set his password, and activate his user account (REGSERVER-1320).

Administration Console

  • Rearranged the menu of the Admin Console and extended the user right levels for viewing, creating, editing and deleting objects (see User Rights).

  • Restricted the view presented by the Admin Console to only those pages that a user has the right to view. Any TeamDrive user with login privileges may login to the Admin Console, and view and manage their resources.

  • Added a global provider drop-down menu, so that users with access to more than one provider can select a Default Provider for all operations.

  • Added account management.

  • Added new categories for Registration Server settings: API, Proxy, RedirectURL and TDNS (REGSERVER-1227).

  • Added an automatic redirect to the login page when the login session expires.

  • If a Depot is deleted and then undeleted on the Host Server, an “Undelete Depot” button is available in the Admin Console to make the depot available again.

  • The “Force Re-Login” function is not always available on the Edit User page. Previously this function was only available if external authentication was in use (REGSERVER-1469).

    The function to “Invalidate Password” is available, in addition if the Super PIN functionality is not enabled, and external authentication is not in use.

    “Force Re-Login” is also available in the Manage Users page, where it effects all user in the selection.

    Forcing a re-login will require the user to login again on all installed devices.

External Authentication

  • All external authentication services (except vasco) now use the same functions to evaluate input and generate the authentication token.

    The services can now be deployed by following the instructions in the *_config.php.example page to create a configuration file, and then customising the HTML in the *_login.php page.

    However, be careful to preserve the PHP dynamic tags in these files, which all have the form: <?= .... ?> and <?php ... ?>.

    Future upgrades will be done (in most cases) by simply replacing all files accept *_login.php and *_lconfig.php.

    Note that the auth directory is now used by all authentication services, and auth\vendor is used by the Google and Azure services.

  • Added support for Google and Azure OAuth2 external authentication. To use these services:

    • follow the instructions in the *_config.php.example page to create a configuration file, and
    • customise the *_login.php page to suite your purpose.
  • Added domain-based selection of the external authentication service (domain directory). The initial page of this service requests the user’s email address. Based on the domain of the email address the user is forwarded to the appropriate authentication service.

    The mapping from domains to authentication services is configured in the dom_config.ini files (see dom_config.ini.example for notes on how to created this file.

    Using this service, the users of a single provider can use various authentication services. If this is the case, then each authentication service must be given a unique name, which is used as a prefix to the external authentication (External Auth. ID) of the user to avoid duplicate IDs.

  • The LDAP external authentication has been updated to evaluate options from various clients, including: the TeamDrive client, the Web Portal, and the TeamDrive agent.

    As a result, the ldap_login.php page can be used in all cases, and the ldap_web_login.php and ldap_agent_login.php pages, are no longer needed, and have been removed.

    Follow the instructions in the ldap_config.php.example page and read the information about the LDAP encryption parameters (see Encryption Parameters) when upgrading from an older version of the LDAP authentication service.

    In addition, the $provider_code setting has been deprecated. When upgrading, copy the value of this variable to the position of the first URL in $allowed_origins (see Agent/Portal Parameters for details).