Merge branch 'master' into import-data-sanitation

docs/Hands-on.md

@@ -33,7 +33,6 @@ Start by creating a base folder for all of the following steps.
 * Clone Repository
     - `git clone https://github.com/ClusterCockpit/cc-backend.git`
     - `cd cc-backend`
-    - `git checkout dev-job-archive-module` Will be merged soon into master
 * Setup Frontend
     - `cd ./web/frontend`
     - `yarn install`
@@ -41,15 +40,15 @@ Start by creating a base folder for all of the following steps.
     - `cd ../..`
 * Build Go Executable
     - `go build ./cmd/cc-backend/`
-* Prepare Datafolder and Database file
-    - `mkdir var`
-    - `touch var/job.db`
 * Activate & Config environment for cc-backend
     - `cp configs/env-template.txt  .env`
     - Optional: Have a look via `vim ./.env`
     - Copy the `config.json` file included in this tarball into the root directory of cc-backend: `cp ../../config.json  ./`
 * Back to toplevel `clustercockpit`
     - `cd ..`
+* Prepare Datafolder and Database file
+    - `mkdir var`
+    - `./cc-backend --migrate-db`
 
 ### Setup cc-metric-store
 * Clone Repository

docs/JWT-Handling.md

@@ -44,3 +44,39 @@ $ ./cc-backend -jwt <username>  -no-server
 ```
 $ curl -X GET "<API ENDPOINT>" -H "accept: application/json"  -H "Content-Type: application/json"  -H "Authorization: Bearer <JWT TOKEN>"
 ```
+
+## Accept externally generated JWTs provided via cookie
+If there is an external service like an AuthAPI that can generate JWTs and hand them over to ClusterCockpit via cookies, CC can be configured to accept them:
+
+1. `.env`: CC needs a public ed25519 key to verify foreign JWT signatures. Public keys in PEM format can be converted with the instructions in [/tools/convert-pem-pubkey-for-cc](../tools/convert-pem-pubkey-for-cc/Readme.md) .
+
+```
+CROSS_LOGIN_JWT_PUBLIC_KEY="+51iXX8BdLFocrppRxIw52xCOf8xFSH/eNilN5IHVGc="
+```
+
+2. `config.json`: Insert a name for the cookie (set by the external service) containing the JWT so that CC knows where to look at. Define a trusted issuer (JWT claim 'iss'), otherwise it will be rejected.
+If you want usernames and user roles from JWTs ('sub' and 'roles' claim) to be validated against CC's internal database, you need to enable it here. Unknown users will then be rejected and roles set via JWT will be ignored.
+
+```json
+"jwts": {
+    "cookieName": "access_cc",
+    "forceJWTValidationViaDatabase": true,
+    "trustedExternalIssuer": "auth.example.com"
+}
+```
+
+3. Make sure your external service includes the same issuer (`iss`) in its JWTs. Example JWT payload:
+
+```json
+{
+  "iat": 1668161471,
+  "nbf": 1668161471,
+  "exp": 1668161531,
+  "sub": "alice",
+  "roles": [
+    "user"
+  ],
+  "jti": "a1b2c3d4-1234-5678-abcd-a1b2c3d4e5f6",
+  "iss": "auth.example.com"
+}
+```

docs/config.json

@@ -1,6 +1,5 @@
 {
-    "addr": "0.0.0.0:8080",
-    "validate": true,
+    "addr":            "127.0.0.1:8080",
     "archive": {
         "kind": "file",
         "path": "./var/job-archive"

docs/searchbar.md

@@ -0,0 +1,35 @@
+# Docs for ClusterCockpit Searchbar
+
+## Usage
+
+* Searchtags are implemented as `type:<query>` search-string
+  * Types `jobId, jobName, projectId, username, name` for roles `admin` and `support`
+    * `jobName` is jobName as persisted in `job.meta_data` table-column
+    * `username` is actual account identifier as persisted in `job.user` table-column
+    * `name` is account owners name as persisted in `user.name` table-column
+  * Types `jobId, jobName, projectId` for role `user`
+  * Examples:
+    * `jobName:myJob12`
+    * `jobId:123456`
+    * `username:abcd100`
+    * `name:Paul`
+* If no searchTag used: Best guess search with the following hierarchy
+  * `jobId -> username -> name -> projectId -> jobName`
+* Destinations:
+  * JobId: Job-Table (Allows multiple identical matches, e.g. JobIds from different clusters)
+  * JobName: Job-Table (Allows multiple identical matches, e.g. JobNames from different clusters)
+  * ProjectId: Job-Table
+  * Username: Users-Table
+    * **Please Note**: Only users with jobs will be shown in table! I.e., Users without jobs will be missing in table.
+  * Name: Users-Table
+    * **Please Note**: Only users with jobs will be shown in table! I.e., Users without jobs will be missing in table.
+  * Best guess search always redirects to Job-Table or `/monitoring/user/$USER` (first username match)
+  * Unprocessable queries will redirect to `/monitoring/jobs/?`
+* Spaces trimmed (both for searchTag and queryString)
+  * `  job12` == `job12`
+  * `projectID : abcd ` == `projectId:abcd`
+* `jobName`- and `name-`queries work with a part of the target-string
+  * `jobName:myjob` for jobName "myjob_cluster1"
+  * `name:Paul` for name "Paul Atreides"
+
+* JobName GQL Query is resolved as matching the query as a part of the whole metaData-JSON in the SQL DB.