fix(admin): вход в панель падал на теге правила, пережившего переименование

RC2 на чистом Debian 13 завершался INSTALL EXIT CODE: 0 при полностью
недоступной панели. На LoginDto.Username стоял тег `validateStr` — правило с
таким именем не регистрировалось: при переименовании в `credentialStr` правка
не доехала до одного файла, оставив мёртвую регистрацию и живую ссылку на
несуществующее имя. go-playground/validator на неизвестный тег ПАНИКУЕТ при
разборе структуры, то есть до всякой проверки логина и пароля, а gin.Recovery
превращал панику в HTTP 500 на каждый POST /api/auth/login.

Дефект пережил 311 Go-тестов, и это главное, что здесь чинится. Проверялся сам
регексп, в обход валидатора, а обработчика входа не касался ни один тест.
Очевидная замена не помогла бы: цепочка правил поля обрывается на первом
несработавшем, поэтому нулевое DTO отказывает по `required` и до испорченного
тега не доходит. Теперь TestEveryValidationTagIsRegistered обходит исходники
apps/model/**, вытаскивает каждый тег `validate:"…"` и предъявляет его
валидатору отдельно — незарегистрированное правило паникует так же, как в бою,
но на сборке. Барьер проверен возвратом исходного тега.

Установка тоже не отвечала на вопрос, ради которого проверялась. Smoke считал
панель работающей по трём признакам — юнит активен, порт в LISTEN, /healthz
отвечает ok, — и все три были истинны. Теперь smoke выполняет настоящий вход
bootstrap-учётными данными и требует конверт успеха с непустым токеном: по коду
HTTP это неотличимо, админка отвечает 200 OK и на отказ. Отрицательная проба
идёт в любом режиме операции и от актуальности пароля не зависит.

Рядом лежали три расхождения того же класса, найденные при разборе.

Оркестратор не знал контракта, который сам порождает: HY2XS_ADMIN_USER по
умолчанию был `admin` — пять символов при минимуме панели в шесть, — и такая
установка проходила целиком, создавая учётную запись, под которой невозможно
войти. Про одно имя существовало три расходящихся умолчания. Оба значения
теперь проверяются при разборе окружения — той стороной, которая их порождает:
отказ, пришедший установщику, чинится строкой в hy2xs.env, а неработающий вход
на готовом сервере — переустановкой.

Панель была строже сервера. Форма входа ограничивала пароль 32 символами при
серверном пределе в 64, а форма смены пароля назначала до 64: пароль,
назначенный штатной операцией, после этого не вводился. Набор символов на
пароле отвергал значение, которое сервер принял бы, — сервер его не
ограничивает нигде. Контракт учётных данных объявлен один раз в
service/admin_credentials.go, копии в панели и оркестраторе сверяются с ним
тестами, читающими Go-исходник.

Класс символов логина был записан диапазоном по опечатке: неэкранированный
дефис превращал `+-=` в диапазон, впускающий `, - . / 0-9 : ; < =`. С серверным
набором это совпадало только потому, что обе стороны несли одну опечатку. Набор
записан явно и НЕ сужен — он уже действует на установленных серверах.

Визуально: красная рамка отказа обводила не то, что видит оператор. Element Plus
рисует состояние ошибки на el-input__wrapper селектором из четырёх классов, а
форма входа рисует видимую рамку поля на el-form-item — внутрь поля кладутся
иконка, ввод и переключатель видимости — и гасила чужую тень селектором из трёх,
проигрывая по специфичности. Рамка ложилась вокруг одного лишь ввода: у логина
начиналась после иконки, у пароля обрывалась перед «глазом». Индикация
перенесена на элемент, который оператор и видит полем; чужая тень гасится
селектором, повторяющим её собственный и добавляющим атрибут scoped-стиля, —
конкретностью, а не !important. Остальные формы панели проверены: собственная
рамка на el-form-item есть только на форме входа.

Заодно: `last_login_at` объявлен в схеме и в entity, а писать его было некому —
UpdateAdminLastLoginAt не вызывался ниоткуда. Отметка ставится в service.Login
сразу после успешной проверки пароля; отказ записи вход не отменяет, но
попадает в журнал. Обработчик входа переехал из controller/peer.go в
controller/auth.go: стек в journal указывал на управление пирами.

Требование теперь называется, а не сообщается фактом нарушения. «Неверный
формат логина» и «Некорректное значение» не давали оператору способа узнать,
что от него хотят: набор символов приходит из hy2xs.env и в панели нигде не
показан. Фразы форм и серверная причина credential_format перечисляют границы
и набор.

Гейт сборки run_admin_login_acceptance удерживает барьеры от тихого удаления —
по той же причине, что и гейт детектора гонок. Каждое из его утверждений
проверено мутационной пробой на реальный отказ; две первые редакции оказались
вакуумными и переписаны.

Прогнано: go vet + go test ./... , bun test оркестратора (427) и контрактов
панели (66), vue-tsc --noEmit, production-сборка frontend, гейт приёмки
целиком. `go test -race` не прогонялся — на машине нет C-компилятора, это
релизный гейт сборщика.

Прогон задокументирован в
docs/acceptance/2026-09-04-v1.0.0-rc2-runtime-findings.md.
This commit is contained in:
2026-09-04 02:32:50 +05:00
parent 82e5ca40cc
commit a8407cf16b
29 changed files with 2409 additions and 77 deletions
@@ -0,0 +1,49 @@
/**
* Контракт учётных данных администратора на стороне панели.
*
* Зачем этот модуль существует. Правила логина и пароля жили прямо в двух
* формах и разошлись и с сервером, и друг с другом:
*
* форма входа логин 6-32 + набор символов, пароль 6-32 + набор
* форма смены пароля пароль 6-64 + набор
* сервер логин 6-32 + набор символов, пароль 6-64 без набора
*
* Следствий было два, и оба закрывали панель. Пароль, назначенный штатной
* формой смены, мог оказаться длиннее 32 символов — и форма входа отказывалась
* его отправлять: оператор терял доступ после операции, которую панель ему же и
* предложила. А набор символов на пароле отвергал значение, которое сервер
* принял бы, — панель была строже сервера там, где она не имеет на это права.
*
* Правило теперь одно на обе формы, и оно сверяется с Go-контрактом
* (apps/service/admin_credentials.go) тестом tools/test/frontend-contract.test.ts.
*/
export const ADMIN_USERNAME_MIN_LENGTH = 6;
export const ADMIN_USERNAME_MAX_LENGTH = 32;
/**
* Набор символов логина в записи регекспа.
*
* Дефис ЭКРАНИРОВАН намеренно. В прежней записи `[a-zA-Z0-9!@#$%^&*()_+-=]` он
* экранирован не был, поэтому `+-=` образовывал ДИАПАЗОН и молча впускал
* `, - . / 0-9 : ; < =`. Действующий набор совпадает с этим фактическим
* множеством — сужать его нельзя, оно уже работает на установленных
* серверах, — но записан явно: пока он выглядел опечаткой, любая попытка
* «навести порядок» развела бы панель и сервер обратно.
*/
const ADMIN_USERNAME_CHARACTER_CLASS = "a-zA-Z0-9!@#$%^&*()_+,\\-./:;<=";
export const ADMIN_USERNAME_PATTERN = new RegExp(
`^[${ADMIN_USERNAME_CHARACTER_CLASS}]{${ADMIN_USERNAME_MIN_LENGTH},${ADMIN_USERNAME_MAX_LENGTH}}$`
);
/** Тот же набор в том виде, в каком его показывают оператору. */
export const ADMIN_USERNAME_CHARSET = "a-z A-Z 0-9 !@#$%^&*()_+,-./:;<=";
/**
* Границы пароля. Набора символов у пароля НЕТ: сервер его не ограничивает ни
* при установке, ни при смене, и панель не имеет права отвергать значение,
* которое сервер принял бы.
*/
export const ADMIN_PASSWORD_MIN_LENGTH = 6;
export const ADMIN_PASSWORD_MAX_LENGTH = 64;
+7 -3
View File
@@ -21,8 +21,12 @@ export default {
password: "Password",
login: "Login",
capsLockOn: "Caps lock is On",
usernameFormatIncorrect: "Username format is incorrect",
passwordFormatIncorrect: "Password format is incorrect",
},
// Требования к учётным данным администратора: общие для формы входа и формы
// смены пароля. См. комментарий в ru.ts.
credentials: {
usernameFormat: "Username: {min} to {max} characters from {charset}",
passwordLength: "Password: {min} to {max} characters",
},
dashboard: {
stale: "Dashboard data is stale. Retrying automatically...",
@@ -161,7 +165,7 @@ export default {
gt: "“{field}”: must be greater than {gt}",
peer_name:
"“{field}”: {min} to {max} characters from {charset}. Spaces, non-latin letters and / : ; . are not allowed",
credential_format: "“{field}”: contains characters that are not allowed",
credential_format: "“{field}”: {min} to {max} characters from {charset}",
rule_violated: "“{field}”: value is not acceptable",
validation_failed: "Validation failed",
body_invalid:
+18 -3
View File
@@ -19,8 +19,19 @@ export default {
password: "Пароль",
login: "Войти",
capsLockOn: "Caps Lock включён",
usernameFormatIncorrect: "Неверный формат логина",
passwordFormatIncorrect: "Неверный формат пароля",
},
// Требования к учётным данным администратора. Фразы общие для формы входа и
// формы смены пароля: требование одно, и второй его формулировки быть не
// должно — расхождение здесь означало бы, что оператору обещают разное про
// одно и то же поле.
//
// Обе фразы НАЗЫВАЮТ требование, а не сообщают о его нарушении. Прежние
// «Неверный формат логина» и «Некорректное значение» не давали оператору ни
// одного способа узнать, что именно от него хотят: набор символов логина
// приходит из hy2xs.env, и посмотреть его в панели негде.
credentials: {
usernameFormat: "Логин: от {min} до {max} символов из набора {charset}",
passwordLength: "Пароль: от {min} до {max} символов",
},
dashboard: {
stale:
@@ -167,7 +178,11 @@ export default {
gt: "«{field}»: значение должно быть больше {gt}",
peer_name:
"«{field}»: от {min} до {max} символов из набора {charset}. Пробелы, кириллица и знаки / : ; . недопустимы",
credential_format: "«{field}»: недопустимые символы",
// Сервер присылает границы и набор в params — фраза называет требование
// целиком. Прежнее «недопустимые символы» вдобавок описывало этими же
// словами отказ по ДЛИНЕ: правило одно, и оно проверяет и то, и другое.
credential_format:
"«{field}»: от {min} до {max} символов из набора {charset}",
rule_violated: "«{field}»: значение не подходит",
validation_failed: "Проверка данных не пройдена",
body_invalid: "Запрос не разобран: проверьте формат и типы полей",
@@ -33,6 +33,10 @@ import { useI18n } from "vue-i18n";
import { useRoute, useRouter } from "vue-router";
import { adminChangePasswordApi } from "@/api/admin";
import { useAdminStore } from "@/store/modules/admin";
import {
ADMIN_PASSWORD_MAX_LENGTH,
ADMIN_PASSWORD_MIN_LENGTH,
} from "@/constants/credentials";
const { t } = useI18n();
const route = useRoute();
@@ -46,7 +50,29 @@ const form = reactive({
newPassword: "",
});
const passwordPattern = /^[a-zA-Z0-9!@#$%^&*()_+-=]{6,64}$/;
// Проверяется ТОЛЬКО длина, и она берётся из общего контракта.
//
// Здесь стояло правило набора символов `[a-zA-Z0-9!@#$%^&*()_+-=]`, которого
// сервер не предъявляет ни при смене пароля, ни при установке. То есть панель
// отказывала оператору в пароле, который сервер принял бы, и сообщала об этом
// фразой «Некорректное значение», не называя ни одного требования.
//
// Границы совпадают с формой входа не случайно: пока они расходились, длинный
// пароль, назначенный здесь, невозможно было ввести там.
//
// Комментарий записан строчными `//`, а не блоком: скан релизных гейтов
// отбрасывает только их, и объяснение, называющее убранную конструкцию по
// имени, иначе роняет проверку «этой конструкции здесь больше нет».
const passwordRule = {
min: ADMIN_PASSWORD_MIN_LENGTH,
max: ADMIN_PASSWORD_MAX_LENGTH,
message: t("credentials.passwordLength", {
min: ADMIN_PASSWORD_MIN_LENGTH,
max: ADMIN_PASSWORD_MAX_LENGTH,
}),
trigger: ["change", "blur"] as string[],
};
const rules: FormRules = {
oldPassword: [
{
@@ -54,11 +80,7 @@ const rules: FormRules = {
message: t("common.required"),
trigger: ["change", "blur"],
},
{
pattern: passwordPattern,
message: t("common.invalid"),
trigger: ["change", "blur"],
},
{ ...passwordRule },
],
newPassword: [
{
@@ -66,11 +88,7 @@ const rules: FormRules = {
message: t("common.required"),
trigger: ["change", "blur"],
},
{
pattern: passwordPattern,
message: t("common.invalid"),
trigger: ["change", "blur"],
},
{ ...passwordRule },
],
};
+79 -4
View File
@@ -83,6 +83,14 @@ import { useAdminStore } from "@/store/modules/admin";
// Зависимость API
import { LocationQuery, LocationQueryValue, useRoute } from "vue-router";
import { AdminLoginDto } from "@/api/admin/types";
import {
ADMIN_PASSWORD_MAX_LENGTH,
ADMIN_PASSWORD_MIN_LENGTH,
ADMIN_USERNAME_CHARSET,
ADMIN_USERNAME_MAX_LENGTH,
ADMIN_USERNAME_MIN_LENGTH,
ADMIN_USERNAME_PATTERN,
} from "@/constants/credentials";
const adminStore = useAdminStore();
const route = useRoute();
@@ -114,6 +122,14 @@ const loginForm = ref<AdminLoginDto>({
pass: "",
});
/**
* Правила формы входа берутся из общего контракта, а не пишутся здесь.
*
* У пароля проверяется ТОЛЬКО длина. Прежнее правило требовало ещё и набор
* символов, из-за чего форма входа отказывалась отправлять пароль, который
* сервер принимает: набор пароля сервер не ограничивает нигде. Проверка,
* которая умеет только запереть оператора и ничего не защищает, — не проверка.
*/
const loginRules = {
username: [
{
@@ -122,8 +138,12 @@ const loginRules = {
trigger: ["change", "blur"],
},
{
pattern: /^[a-zA-Z0-9!@#$%^&*()_+-=]{6,32}$/,
message: t("login.usernameFormatIncorrect"),
pattern: ADMIN_USERNAME_PATTERN,
message: t("credentials.usernameFormat", {
min: ADMIN_USERNAME_MIN_LENGTH,
max: ADMIN_USERNAME_MAX_LENGTH,
charset: ADMIN_USERNAME_CHARSET,
}),
trigger: ["change", "blur"],
},
],
@@ -134,8 +154,12 @@ const loginRules = {
trigger: ["change", "blur"],
},
{
pattern: /^[a-zA-Z0-9!@#$%^&*()_+-=]{6,32}$/,
message: t("login.passwordFormatIncorrect"),
min: ADMIN_PASSWORD_MIN_LENGTH,
max: ADMIN_PASSWORD_MAX_LENGTH,
message: t("credentials.passwordLength", {
min: ADMIN_PASSWORD_MIN_LENGTH,
max: ADMIN_PASSWORD_MAX_LENGTH,
}),
trigger: ["change", "blur"],
},
],
@@ -205,10 +229,61 @@ const handleLogin = () => {
}
}
// Видимое поле формы входа — это `el-form-item`, а не `el-input`.
//
// Рамка и фон нарисованы здесь, потому что внутрь одного поля кладутся три
// вещи: иконка, ввод и переключатель видимости пароля. `el-input` занимает лишь
// среднюю из них.
//
// Отсюда и дефект индикации ошибки, который был виден на форме. Element Plus
// рисует состояние отказа на `el-input__wrapper` правилом
//
// .el-form-item.is-error .el-form-item__content .el-input__wrapper
//
// то есть селектором из ЧЕТЫРЁХ классов, а здешнее гашение тени записывалось
// селектором из трёх — и проигрывало по специфичности. В результате красная
// рамка ложилась вокруг одного лишь поля ввода: у логина она начиналась после
// иконки пользователя, у пароля обрывалась перед «глазом», и ни одна её сторона
// не совпадала с видимой границей поля.
//
// Чинится это не увеличением специфичности ради победы, а переносом индикации
// на тот элемент, который оператор и видит полем.
.el-form-item {
background: var(--subMenuBg);
border: 1px solid rgb(255 255 255 / 12%);
border-radius: 5px;
// Просвет под полем принадлежит сообщению об отказе: `el-form-item__error`
// позиционируется абсолютно от `top: 100%`, то есть живёт ВНЕ рамки. При
// стандартных 18px оно вплотную прижималось к границе снизу и к следующему
// полю сверху.
margin-bottom: 26px;
&.is-error {
border-color: var(--el-color-danger);
// Штатная индикация Element Plus гасится ЗДЕСЬ, а не в блоке `.el-input`:
// селектор повторяет её собственный и добавляет атрибут scoped-стиля,
// поэтому выигрывает по специфичности. Прежнее гашение стояло на два
// класса ниже и проигрывало — из-за чего красный прямоугольник вокруг
// одного лишь поля ввода и появлялся. `!important` здесь не нужен: правило
// не сильнее чужого, а конкретнее.
:deep(.el-form-item__content .el-input__wrapper) {
&,
&:hover,
&:focus,
&.is-focus {
box-shadow: none;
}
}
}
// Сообщение выравнивается по тексту поля, а не по краю рамки: иначе оно
// висит на сдвиг левее всего, что находится над ним.
:deep(.el-form-item__error) {
padding-top: 6px;
padding-left: 12px;
}
}
.el-input {