Api key migrations (#36316)

* Part 1: Add `core_user.type`

With the addition of API keys and "api key users", we want to add a `type` field to users to easily distinguish
between "regular" users and API key users.

The one non-standard user we have right now is the "internal" Metabase user. We don't actually need this field for
that one (because we fix that user's ID to `13371338`), but we might as well set the `type` correctly anyway.

* Part 2: API Key table

Create an API Key table to contain, uh, API keys.

The table has the following fields:

- id

- user_id (the associated API key user, who this API key "acts as")

- key (the hash of the API key itself)

- key_prefix (the first 7 digits of the *raw* API key, beginning with `mb_XXXX`)

- created_by (the user that created the API key)

- created_at

- updated_at

* Part 3: Set the type of the internal user

The internal user is actually identified by the ID, but we might as well set the type correctly.


Finally: don't condition view recompilation on is-prod? since Cypress actually runs the backend in prod mode

---------

Co-authored-by: Noah Moss <noahbmoss@gmail.com>

enterprise/backend/src/metabase_enterprise/internal_user.clj

@@ -15,7 +15,8 @@
     :is_active false
     :is_superuser false
     :login_attributes nil
-    :sso_source nil}))
+    :sso_source nil
+    :type :internal}))
 
 (defn ensure-internal-user-exists!
   "Creates the internal user"

resources/migrations/001_update_migrations.yaml

@@ -4198,6 +4198,120 @@ databaseChangeLog:
 
   - changeSet:
       id: v49.00-003
+      author: johnswanson
+      comment: Add a `type` to users
+      changes:
+        - addColumn:
+            columns:
+              - column:
+                  name: type
+                  type: varchar(64)
+                  constraints:
+                    nullable: false
+                  defaultValue: 'personal'
+                  remarks: The type of user
+            tableName: core_user
+
+  - changeSet:
+      id: v49.00-004
+      author: johnswanson
+      comment: Add a table for API keys
+      changes:
+        - createTable:
+            tableName: api_key
+            remarks: An API Key
+            columns:
+              - column:
+                  remarks: The ID of the API Key itself
+                  name: id
+                  type: int
+                  autoIncrement: true
+                  constraints:
+                    primaryKey: true
+                    nullable: false
+              - column:
+                  name: user_id
+                  type: int
+                  remarks: The ID of the user who this API Key acts as
+                  constraints:
+                    nullable: false
+                    referencedTableName: core_user
+                    referencedColumnNames: id
+                    foreignKeyName: fk_api_key_user_id
+              - column:
+                  remarks: The hashed API key
+                  name: key
+                  type: varchar(254)
+                  constraints:
+                    nullable: false
+              - column:
+                  remarks: The first 7 characters of the unhashed key
+                  name: key_prefix
+                  type: varchar(7)
+                  constraints:
+                    nullable: false
+                    unique: true
+              - column:
+                  remarks: The ID of the user that created this API key
+                  name: created_by
+                  type: integer
+                  constraints:
+                    nullable: false
+                    referencedTableName: core_user
+                    referencedColumnNames: id
+                    foreignKeyName: fk_api_key_created_by_user_id
+              - column:
+                  remarks: The timestamp when the key was created
+                  name: created_at
+                  type: ${timestamp_type}
+                  defaultValueComputed: current_timestamp
+                  constraints:
+                    nullable: false
+              - column:
+                  remarks: The timestamp when the key was last updated
+                  name: updated_at
+                  type: ${timestamp_type}
+                  defaultValueComputed: current_timestamp
+                  constraints:
+                    nullable: false
+
+  - changeSet:
+      id: v49.00-005
+      author: johnswanson
+      comment: Add an index on `api_key.created_by`
+      rollback: # not necessary, will be removed with the table
+      changes:
+        - createIndex:
+            tableName: api_key
+            indexName: idx_api_key_created_by
+            columns:
+              column:
+                name: created_by
+
+  - changeSet:
+      id: v49.00-006
+      author: johnswanson
+      comment: Add an index on `api_key.user_id`
+      rollback: # not necessary, will be removed with the table
+      changes:
+        - createIndex:
+            tableName: api_key
+            indexName: idx_api_key_user_id
+            columns:
+              column:
+                name: user_id
+
+  - changeSet:
+      id: v49.00-007
+      author: johnswanson
+      comment: Set the `type` of the internal user
+      changes:
+        - sql:
+            sql: UPDATE core_user SET type='internal' WHERE id=13371338;
+      rollback: # not necessary
+
+  - changeSet:
+      id: v49.00-008
       author: qnkhuat
       comment: Add metabase_field.database_indexed
       changes:

src/metabase/api/testing.clj

@@ -75,14 +75,13 @@
     ;; the generated snapshot has the `CREATE VIEW` *before* the `CREATE TABLE`. This results in a view that can't be
     ;; queried successfully until it is recompiled. Our workaround is to recompile ALL views immediately after we
     ;; restore the app DB from a snapshot. Bug report is here: https://github.com/h2database/h2database/issues/3942
-    (when (not config/is-prod?)
-      (doseq [table-name
-              (->> (jdbc/query {:connection conn} ["SELECT table_name FROM information_schema.views WHERE table_schema=?" "PUBLIC"])
-                   (map :table_name))]
-        ;; parameterization doesn't work with view names. If someone maliciously named a table, this is bad. On the
-        ;; other hand, this is not running in prod and you already had to have enough access to maliciously name the
-        ;; table, so this is probably safe enough.
-        (jdbc/execute! {:connection conn} (format "ALTER VIEW %s RECOMPILE" table-name)))))
+    (doseq [table-name
+            (->> (jdbc/query {:connection conn} ["SELECT table_name FROM information_schema.views WHERE table_schema=?" "PUBLIC"])
+                 (map :table_name))]
+      ;; parameterization doesn't work with view names. If someone maliciously named a table, this is bad. On the
+      ;; other hand, this is not running in prod and you already had to have enough access to maliciously name the
+      ;; table, so this is probably safe enough.
+      (jdbc/execute! {:connection conn} (format "ALTER VIEW %s RECOMPILE" table-name))))
   ;; don't know why this happens but when I try to test things locally with `yarn-test-cypress-open-no-backend` and a
   ;; backend server started with `dev/start!` the snapshots are always missing columms added by DB migrations. So let's
   ;; just check and make sure it's fully up to date in this scenario. Not doing this outside of dev because it seems to

src/metabase/models/user.clj

@@ -52,7 +52,11 @@
 (t2/deftransforms :model/User
   {:login_attributes mi/transform-json-no-keywordization
    :settings         mi/transform-encrypted-json
-   :sso_source       mi/transform-keyword})
+   :sso_source       mi/transform-keyword
+   :type             mi/transform-keyword})
+
+(def ^:private allowed-user-types
+  #{:internal :personal})
 
 (def ^:private insert-default-values
   {:date_joined  :%now
@@ -86,6 +90,9 @@
   ;; these assertions aren't meant to be user-facing, the API endpoints should be validation these as well.
   (assert (u/email? email))
   (assert ((every-pred string? (complement str/blank?)) password))
+  (when-let [user-type (:type user)]
+    (assert
+     (contains? allowed-user-types user-type)))
   (when locale
     (assert (i18n/available-locale? locale) (tru "Invalid locale: {0}" (pr-str locale))))
   (merge