SHA256
Добавить SHiNE теги в DM и безопасный рендер превью
This commit is contained in:
AidarKC
@@ -0,0 +1,26 @@
|
||||
## Краткое описание
|
||||
|
||||
В DM добавлен клиентский формат технических вставок в начале plaintext:
|
||||
|
||||
- `<SHiNE:reply;v=1;id=...>`
|
||||
- `<SHiNE:call;v=1;status=...;...>`
|
||||
|
||||
UI скрывает такие вставки из текста сообщения, а call-вставки отображает специальным человекочитаемым видом.
|
||||
Также добавлена защита от пользовательского текста, начинающегося с `<SHiNE:`, и исправлен безопасный рендер превью последнего сообщения в списке личных диалогов.
|
||||
|
||||
## Что проверять
|
||||
|
||||
- Если пользователь отправляет обычный текст, начинающийся с `<SHiNE:`, он уходит как `< SHiNE:` и отображается как обычный текст.
|
||||
- DM с `<SHiNE:call...>` показывается в чате как специальное call-сообщение, а не как сырой техтекст.
|
||||
- В списке личных сообщений превью такого сообщения показывает человекочитаемый итог звонка.
|
||||
- DM с `<SHiNE:reply...>Текст ответа` скрывает техблок и показывает только `Текст ответа`.
|
||||
- Если reply-цель отсутствует, сообщение всё равно показывается как обычный текст ответа.
|
||||
- Текст вида `<script>alert(1)</script>` или похожие HTML-теги не исполняются ни в чате, ни в списке личных сообщений, ни в списке каналов.
|
||||
|
||||
## Ожидаемый результат
|
||||
|
||||
Технические SHiNE-вставки работают только как управляющие метаданные UI, а отображаемый пользователю текст и превью остаются безопасными и не рендерят HTML.
|
||||
|
||||
## Статус
|
||||
|
||||
pending
|
||||
@@ -6,6 +6,7 @@
|
||||
|
||||
- `Dev_Docs/Personal_Messages/Протокол_DM_v1.md` — логика протокола, роли API, серверное поведение, routing по `access_servers`
|
||||
- `Dev_Docs/Personal_Messages/Формат_DM_v1.md` — точный бинарный формат контейнера `SHiNE_DM`
|
||||
- `Dev_Docs/Personal_Messages/Технические_вставки_DM_v1.md` — формат специальных `<SHiNE:...>` вставок внутри plaintext DM после расшифровки
|
||||
|
||||
Исторический устаревший документ сохранён отдельно:
|
||||
|
||||
|
||||
@@ -22,6 +22,10 @@
|
||||
|
||||
- `Dev_Docs/Personal_Messages/Формат_DM_v1.md`
|
||||
|
||||
Формат клиентских технических вставок внутри plaintext вынесен отдельно:
|
||||
|
||||
- `Dev_Docs/Personal_Messages/Технические_вставки_DM_v1.md`
|
||||
|
||||
Устаревшая предыдущая версия сохранена отдельно:
|
||||
|
||||
- `Dev_Docs/Personal_Messages/Спецификация_DM_v0.5_устаревшая.md`
|
||||
@@ -92,6 +96,9 @@
|
||||
- если формат понятен, но расшифровка не удалась, показывает `Не удалось расшифровать сообщение`;
|
||||
- если `body` повреждён или структурно битый, показывает `Сообщение повреждено`.
|
||||
|
||||
После успешной расшифровки plaintext может дополнительно содержать специальные клиентские вставки `<SHiNE:...>` в начале текста.
|
||||
Эти вставки относятся уже к уровню UI/plaintext, а не к уровню серверного DM-envelope.
|
||||
|
||||
### 2.4. Источник истины по пользователю
|
||||
|
||||
Для DM-проверки сервер использует:
|
||||
|
||||
@@ -0,0 +1,145 @@
|
||||
# Технические вставки внутри plaintext DM v1
|
||||
|
||||
## Статус документа
|
||||
|
||||
Этот файл описывает внутренний формат технических вставок, которые находятся внутри уже расшифрованного plaintext DM.
|
||||
|
||||
Важно:
|
||||
|
||||
- это не отдельный серверный DM-envelope;
|
||||
- это часть plaintext контентного DM после E2EE-расшифровки;
|
||||
- сервер не обязан знать этот формат;
|
||||
- клиент может использовать эти вставки для специального UI-рендера.
|
||||
|
||||
## 1. Общий принцип
|
||||
|
||||
Обычное сообщение по-прежнему остаётся обычным текстом.
|
||||
|
||||
Если в начале plaintext стоит один или несколько специальных блоков формата:
|
||||
|
||||
```text
|
||||
<SHiNE:...>
|
||||
```
|
||||
|
||||
то клиент трактует их как технические вставки.
|
||||
|
||||
Техническими считаются только блоки, которые:
|
||||
|
||||
- стоят строго в начале plaintext;
|
||||
- начинаются с точного префикса `<SHiNE:`;
|
||||
- заканчиваются первым символом `>`.
|
||||
|
||||
Если текст не начинается с `<SHiNE:`, никакие технические вставки не ищутся.
|
||||
|
||||
## 2. Правило скрытия
|
||||
|
||||
Все корректно распознанные блоки `<SHiNE:...>` в начале plaintext:
|
||||
|
||||
- не показываются пользователю как сырой текст;
|
||||
- используются клиентом для UI-логики;
|
||||
- неизвестные будущие типы тоже скрываются, если они распознаны как корректный SHiNE-блок.
|
||||
|
||||
Если блок битый и не закрыт символом `>`, он не считается техническим и сообщение показывается как обычный текст целиком.
|
||||
|
||||
## 3. Защита от случайного пользовательского ввода
|
||||
|
||||
Перед отправкой обычного текстового сообщения клиент обязан проверить:
|
||||
|
||||
- если пользовательский текст начинается с `<SHiNE:`
|
||||
|
||||
то клиент автоматически превращает начало в:
|
||||
|
||||
```text
|
||||
< SHiNE:
|
||||
```
|
||||
|
||||
Такой текст уже не считается техническим блоком и должен отображаться как обычное сообщение.
|
||||
|
||||
## 4. Формат блока
|
||||
|
||||
Общий вид:
|
||||
|
||||
```text
|
||||
<SHiNE:kind;key=value;key=value;...>
|
||||
```
|
||||
|
||||
Правила:
|
||||
|
||||
- `kind` — ASCII-идентификатор типа вставки;
|
||||
- параметры отделяются `;`;
|
||||
- ключ и значение отделяются `=`;
|
||||
- значения не экранируются в v1;
|
||||
- формат чувствителен к точному префиксу `<SHiNE:`.
|
||||
|
||||
## 5. Тип `reply`
|
||||
|
||||
Формат:
|
||||
|
||||
```text
|
||||
<SHiNE:reply;v=1;id=user1|user2|1720612345678|77>Текст ответа
|
||||
```
|
||||
|
||||
Где поле `id` — это логический идентификатор сообщения:
|
||||
|
||||
```text
|
||||
fromLogin|toLogin|timeMs|nonce
|
||||
```
|
||||
|
||||
Правила:
|
||||
|
||||
- этот блок должен стоять в начале plaintext;
|
||||
- после него может идти обычный текст ответа;
|
||||
- если клиент не находит сообщение, на которое ссылается `reply`, он просто не показывает reply-preview;
|
||||
- в таком случае само сообщение отображается как обычный текст без блока `<SHiNE:reply...>`.
|
||||
|
||||
## 6. Тип `call`
|
||||
|
||||
### Успешный звонок
|
||||
|
||||
```text
|
||||
<SHiNE:call;v=1;status=completed;duration=367>
|
||||
```
|
||||
|
||||
Где:
|
||||
|
||||
- `duration` — длительность разговора в секундах.
|
||||
|
||||
### Неуспешный звонок
|
||||
|
||||
```text
|
||||
<SHiNE:call;v=1;status=failed;reason=offline>
|
||||
```
|
||||
|
||||
Допустимые причины в v1:
|
||||
|
||||
- `offline`
|
||||
- `no_answer`
|
||||
- `connect_failed`
|
||||
- `busy`
|
||||
- `declined`
|
||||
|
||||
Правила:
|
||||
|
||||
- call-блок в v1 должен содержать только техническую запись звонка;
|
||||
- пользовательский текст после такого блока в штатной логике не предполагается;
|
||||
- UI может рисовать такие сообщения отдельным специальным стилем.
|
||||
|
||||
## 7. Поведение официального UI
|
||||
|
||||
Официальный UI SHiNE в v1:
|
||||
|
||||
- скрывает все корректные `<SHiNE:...>` блоки в начале plaintext;
|
||||
- для `call` строит специальный человекочитаемый текст:
|
||||
- `Звонок: M:SS`
|
||||
- `Звонок: H:MM:SS`
|
||||
- `Звонил, но недозвонился: ...`
|
||||
- для `reply` скрывает сам блок и показывает только текст ответа;
|
||||
- если исходное reply-сообщение не найдено, reply-preview не показывается.
|
||||
|
||||
## 8. Совместимость
|
||||
|
||||
Так как это часть plaintext, а не часть серверного envelope:
|
||||
|
||||
- сервер не обязан понимать этот формат;
|
||||
- будущие клиенты могут добавлять новые `kind`;
|
||||
- клиенты, которые распознают SHiNE-вставки, должны скрывать неизвестные блоки целиком, если они стоят в начале и корректно закрыты.
|
||||
Reference in New Issue
Block a user