Remove test token feature

docs/DEVELOPMENT.md

@@ -174,7 +174,6 @@ You can use an existing backup of the database (PostgreSQL 13+) by a command lik
 ```bash
 mvn  quarkus:dev -pl '!horreum-integration-tests' \
   -Dhorreum.dev-services.postgres.database-backup=/opt/databases/horreum-prod-db/ \
-  -Dhorreum.db.secret='M3g45ecr5t!' \
   -Dhorreum.dev-services.keycloak.db-password='prod-password' \
   -Dhorreum.dev-services.keycloak.admin-password='ui-prod-password' \
   -Dquarkus.datasource.username=user \
@@ -193,8 +192,6 @@ horreum.dev-services.keycloak.db-password=<keycloak-user-password>
 horreum.dev-services.keycloak.admin-username=<keycloak-admin-name>
 horreum.dev-services.keycloak.admin-password=<keycloak-admin-password>
 
-horreum.db.secret=<db-secret>
-
 quarkus.datasource.username=<horreum-user-name>
 quarkus.datasource.password=<horreum-user-password>
 

docs/SECURITY.md

@@ -2,17 +2,11 @@
 
 Security uses RBAC with authz and authn provided by Keycloak server, and heavily relies on row-level security (RLS) in the database.
 There should be two DB users (roles); `dbadmin` who has full access to the database, and `appuser` with limited access.
-`dbadmin` should set up DB structure - tables with RLS policies and grant RW access to all tables but `dbsecret` to `appuser`.
+`dbadmin` should set up DB structure - tables with RLS policies and grant RW access to all tables to `appuser`.
 When the application performs a database query, impersonating the authenticated user, it invokes `SET horreum.userroles = '...'`
 to declare all roles the user has based on information from Keycloak. RLS policies makes sure that the user cannot read or modify
 anything that does not belong to this user or is made available to him.
 
-As a precaution against bug leaving SQL-level access open the `horreum.userroles` granting the permission are not set in plaintext;
-the format of the setting is `role1:seed1:hash1,role2:seed2:hash2,...` where the `hash` is SHA-256 of combination of role, seed
-and hidden passphrase. This passphrase is set in `application.properties` under key `horreum.db.secret`, and in database as the only
-record in table `dbsecret`. The user `appuser` does not have access to that table, but the security-defined functions used
-in table policies can fetch it, compute the hash again and validate its correctness.
-
 We define 3 levels of access to each row:
 
 - public: available even to non-authenticated users (for reading)

docs/site/content/en/docs/Deployment/bare-metal.md

@@ -89,8 +89,6 @@ QUARKUS_DATASOURCE_MIGRATION_PASSWORD=Curr3ntAdm!nPwd
 QUARKUS_DATASOURCE_JDBC_ADDITIONAL-JDBC-PROPERTIES_SSLROOTCERT=server.crt
 # As an alternative, certificate validation can be disabled with
 # QUARKUS_DATASOURCE_JDBC_ADDITIONAL-JDBC-PROPERTIES_SSLMODE=require
-# Secret generated during database setup: run `SELECT * FROM dbsecret` as DB admin
-HORREUM_DB_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxx
 
 # --- KEYCLOAK ---
 # This URL must be accessible from Horreum, but does not have to be exposed to the world

docs/site/content/en/docs/Tasks/upload-run/index.md

@@ -10,13 +10,13 @@ Horreum accepts any valid **JSON** as the input. To get maximum out of Horreum,
 There are two principal ways to authorize operations:
 
 - Authentication against OIDC provider (Keycloak): This is the standard way that you use when accessing Horreum UI - you use your credentials to get a JSON Web Token (JWT) and this is stored in the browser session. When accessing Horreum over the REST API you need to use this for [Bearer Authentication](https://datatracker.ietf.org/doc/html/rfc6750#section-2.1). The authorization is based on the teams and roles within those teams that you have.
-- Horreum Tokens: In order to provide access to non-authenticated users via link, or let automated scripts perform tasks Horreum can generate a random token consisting of 80 hexadecimal digits. This token cannot be used in the `Authorization` header; operations that support tokens usually accept `token` parameter.
+- Horreum API Keys: See more in [API keys](/docs/tasks/api-keys). These replace the so called "Horreum Tokens" that were used in the past in operations that accepted a `token` parameter. 
 
 If you're running your tests in Jenkins you can skip a lot of the complexity below using [Horreum Plugin](https://plugins.jenkins.io/horreum/). This plugin supports both Jenkins Pipeline and Freeform jobs.
 
 ## Getting JWT token
 
-New data can be uploaded into Horreum only by authorized users. We recommend setting up a separate user account for the load-driver (e.g. [Hyperfoil](https://hyperfoil.io)) or CI toolchain that will upload the data as part of your benchmark pipeline. This user must have the permission to upload for given team, e.g. if you'll use `dev-team` as the owner this role is called `dev-uploader` and it is a composition of the team role (`dev-team`) and `uploader` role. You can read more about user management [here](/docs/concepts/users).
+New data can be uploaded into Horreum only by authorized users. This user must have the permission to upload for given team, e.g. if you'll use `dev-team` as the owner this role is called `dev-uploader` and it is a composition of the team role (`dev-team`) and `uploader` role. You can read more about user management [here](/docs/concepts/users).
 
 ```bash
 TOKEN=$(curl -s http://localhost:8180/realms/horreum/protocol/openid-connect/token \
@@ -44,12 +44,6 @@ TOKEN=$(curl -s http://localhost:8180/realms/horreum/protocol/openid-connect/tok
 
 Note that the offline token also expires eventually, by default after 30 days.
 
-## Getting Horreum token
-
-In order to retrieve an upload token you need to navigate to particular Test configuration page, switch to tab 'Access' and push the 'Add new token' button, checking permissions for 'Read' and 'Upload'. The token string will be displayed only once; if you lose it please revoke the token and create a new one.
-
-This token should not be used for Bearer Authentication (do not use it in the `Authorization` HTTP header) as in the examples below; instead you need to append `&token=<horreum-token>` to the query.
-
 ## Uploading the data
 
 There are several mandatory parameters for the upload: