SysAdmin On-Premises


In On-Premises instances, using the SysAdmin page you can perform different management tasks at the system level.

How to access

Go to your root domain set for tagtog (you probably use directly the IP or a custom domain) and access /-sysadmin relative path. For example: You will be prompted with a basic authentication panel, to enter the fields:

Username: use the subscription license name

Password: use the subscription license key

Username, email address, and registration date.


User Management

The admin panel displays a list of the users registered in the instance. You can:

Create new accounts: generate a registration link to share with others or to use oneself

Edit accounts: edit the users’ accounts main information, namely, username, email, and password. 📝

Remove old accounts: remove users that for example do not use anymore the application. Remove a user from the system by clicking on the remove button .

Revoke all auth tokens: remove all existing token-based logins and registration links

Roles and permissions

In the admin panel you can find a permission matrix where you can check/modify the permissions of existing roles or to create custom roles. After, these roles can be assigned to users at project level.

All the permissions are explained here: Multi-user annotation - permissions

By default there are three roles in the system: admin, supercurator and reader. The permissions for these default roles cannot be modified. Admin role cannot be removed (the creator of a project, the owner, will always have this role assigned). The roles supercurator and reader can be removed. If you want to modify their permissions, you should remove the role, and create a new role with the same name.

To create a new role simply click on Add new role. To change a permission, you should click on the corresponding checkbox. If you hover on the permission name or on a role name, a description of the permission or the role will show up.

For each role, you can perform three actions:

Edit its name/description

Remove it. If you remove a role, you should indicate which is the role that will be assigned to all the users once their original role is removed.

Change its permissions

Permission matrix. In this example, in addition to the default roles, there is a new role myNewRole

Single Sign-On (SSO)

The current SSO system on tagtog is based on authentication tokens. These can only be generated by the sysadmin (via API). The sysadmin can then have injected, in a simple reverse proxy server or just simple URL redirections, the corresponding authentication token that distinctively grant one user to login. The sysadmin can keep an internal map of reusable tokens or generate them on-demand programatically any time a login access is required (see below the useOnce API parameter). All auth tokens can easily be deleted at any time (see above: Revoke all auth tokens).

API to request auth token

Endpoint /-sysadmin/request-auth-token
Method POST
Output String, the auth token

Input Parameters

Defined as JSON parameters:

Name Default Example Description
toUsername (String) - yourUsername The user's username you grant the authentication to.
expirationHours (Int) -1 (meaning, no expiration) 24 The expiration in hours for the token to still be usable. Leave undefined or otherwise write a negative number to not have any expiration (meaning the token is valid until removed).
useOnce (Boolean) false true Besides the expiration, with this parameter you can decide whether the token can be used only once (true) or not (false, i.e., multiple times until the token is removed or expires).

Coding examples

curl -u LICENSE_NAME:LICENSE_KEY -X POST -H "Content-Type: application/json" '' \
-d '{"toUsername": "yourUsername", "useOnce": true, "expirationHours": 48}'
# Example output: bbfd-33878148-6062-4934-a507-af4962753c8f
http --verify no --auth LICENSE_NAME:LICENSE_KEY POST '' toUsername=yourUsername useOnce:=false
# Example output: 6f0d-90c2386a-8a33-4ad1-bd19-d4d35ad06f96

How to use an auth token

Once you have an auth token, use it in a simple GET request to login with the associated-granted user. To the request also add a redirectTo (url-encoded) parameter to indicate where to redirect to. You must add these parameters to the / (root endpoint) of your tagtog's installation domain.


Tighter authorization

Sometimes you might want to have a tighter control about what the users and visitors of your system are allowed to do. You can configure the following authorization controls using java dynamic properties. Specifically, you must properly set the environment variable TAGTOG_JAVA_OPTS with the desired configuration values as described for each point below.

Disallow visitors to create accounts

Sometimes you do not want to allow visitors to your tagtog installation creating accounts themselves. In such a case, the sysadmin is responsible to create the accounts for all the users.

Set (the java dynamic property) application.canVisitorsCreateAccounts to false (the default is true). Example:

export TAGTOG_JAVA_OPTS="${TAGTOG_JAVA_OPTS} -Dapplication.canVisitorsCreateAccounts=false"; ./tagtog_on_premises restart latest $PWD/tagtog_home

Disallow users to change their account details

In such a case, the sysadmin is responsible to edit the account details of the users.

Set application.canUsersEditTheirAccounts to false (the default is true). Example:

export TAGTOG_JAVA_OPTS="${TAGTOG_JAVA_OPTS} -Dapplication.canUsersEditTheirAccounts=false"; ./tagtog_on_premises restart latest $PWD/tagtog_home

Disallow users to recover their passwords using the "Forgot Password?" email

In such a case, the sysadmin is entirely responsible for the users’ passwords.

Set application.canUsersRequestForgotPassword to false (the default is true). Example:

export TAGTOG_JAVA_OPTS="${TAGTOG_JAVA_OPTS} -Dapplication.canUsersRequestForgotPassword=false"; ./tagtog_on_premises restart latest $PWD/tagtog_home