Проще способ подойдет не для всех, но все же, используем только замороженые ури:

if (!$useFrozenPathUris) { $parentResources[]= "{$parentAlias}"; }


Не за что!

И еще раз уточню, на всякий случай: то, что записано в JWT, общедоступно и читаемо. То есть нельзя что-то приватное записывать в JWT. Хоть оно в виде обычной строки и человеконечитаемо, все-таки оно дешифруемо. Суть использования JWT в таком виде сводится к тому, чтобы не просто передать какие-то текстовые данные, а еще и подписать их для проверки подлинности в дальнейшем. То есть на стороне сервера вы создаете JWT-token (масло-масленое, ибо аббревиатура JWT уже включает в себя Token), используя ключ, который никто не должен знать, потому как есть знает, он может модифицировать запись и подписать ее этим ключом, и тогда сервер примет этот токен, что совсем не есть хорошо. Этот момент надо четко понимать. А то некоторые, видя нечитаемую строку, думают, что в нее можно записывать все, что угодно. Нет, это совсем не так.
В принципе я именно так, все себе и представлял. Но вчера при практической реализации подумал, что наверное все должно быть гораздо сложнее, плюс мой внутренний параноик начал бомбить.
Большое спасибо за развернутый ответ с примерами!
p.s. подтверждаю, багули пропали.
>>> Вот сейчас в другом браузере открыл приватную вкладку, вбил туда свой токен и вуаля, я авторизован.
Собственно так и должно быть, ведь у вас в наличии есть токен, созданый для идентификации пользователя. Есть токен валидный - есть авторизация.
Тут, конечно, стоит отдельно оговорить, что кукисы есть разные. Есть http-only, которые чаще всего и используются для хранения для PHP-сессий и которые не могут быть просто так прочитаны средствами JS (точнее вообще не должны ими читаться, а читаются и устанавливаются только серверными соединениями). Но http-only куки не панацея, и не являются обязательным механизмом авторизации. В современном интернете все чаще используют токены. В данном случае реализация на JWT. Статья на хабре: https://habr.com/ru/post/340146/

То есть в нашем случае используются именно токены, и это практически обязательно для принципа API-first CMS и т.п. Собственно, так изначально и был расчет: не важно на каком устройстве ты авторизовался и получил свой токен, ты его можешь в дальнейшем использовать где угодно (пока он принимается API-сервером). Так что ваша задача просто не слить свой токен кому попало. Хотя я соглашусь, что есть еще куда усиливать безопасность и позже я этим займусь. Но сейчас это пока преждевременная оптимизация.

И да, если вы хотите на своем проекте усилить авторизацию своими средствами, это можно.
Вот здесь токен создается, когда пользователь авторизовывается: https://github.com/prisma-cms/user-module/blob/7fc769cbf1635799442fdd798f6c2f209fa7a8c2/src/modules/index.mjs#L110

А вот здесь он проверяется, когда приходит API-запрос: https://github.com/prisma-cms/prisma-context/blob/8a4384ee6d3dbdc2e8eb67bdd2661a800cad5b18/src/index.mjs#L54

То есть используется следующий принцип при обработке запросов: когда на сервер приходит API-запрос, выполняется попытка идентифицировать пользователя. Если пользователь был получен, он добавляется в контекст текущего запроса, чтобы в процессе его обработки на всех уровнях GraphQL-резолверов его можно было получить из текущего контекста.

К примеру, практически все конечные серверные модули prisma-cms используют @prisma-cms/prisma-processor, и вот в нем выполняется попытка получить текущего пользователя: https://github.com/prisma-cms/prisma-processor/blob/375e361a3b2a46aeb4efd42b233dc3c08ec2e3b7/src/index.mjs#L286
То есть не выполняется запроса к БД или типа того, а просто он дергается из контекста.
Выкатил обновления. Сейчас с сообщениями должно быть ОК. Заодно пофиксил давнюю багу с кешем комментариев: когда начинаешь писать коммент в одном топике, а потом замечаешь, что не туда пишешь, переходишь в другой, постишь коммент, а он улетает в исходный топик. Больше такой проблемы нет. При чем можно иметь сразу несколько черновиков комментариев в разных топиках (по одному на топик).
Вам спасибо!
Прошу прощения, что не в тему топика, но не могли бы вы просто, тезисно, рассказать об организации процесса авторизации на вашем сайте? Просто я пытаюсь мигрировать с php на js, сейчас разбираюсь с авторизацией и мне стало интересно какие способы хранения токена используют в реальных проектах. У вас на на сайте используется локальное хранилище, но насколько я знаю оно совсем не безопасно, этож те же куки только в профиль, разве нет? Вот сейчас в другом браузере открыл приватную вкладку, вбил туда свой токен и вуаля, я авторизован.
<< И после публикации комментария, не обновляется форма -)
Да, действительно не пропадает. Но возможно исправится после обновления компонентов (я там немного со сбросом кеша и коллбэками переделывал). Перепроверю дополнительно. Спасибо!
>> Николай, может стоит на главной странице или рядом с выбором языка, добавить ссылку на гит prinsma-cms?
ОК, воткну куда-нибудь.

>> Ну и у вас "dfgfdg " болтается в левом нижнем углу.
Да, в одну из зависимостей отладочная информация затесалась, оттуда уже убрал, но здесь пока не обновлял, потому что довольно много изменений прилетит, под которые и здесь код немного актуализировать надо будет (грядут новшества :)). Так что еще немного повисит, потом пропадет.
И после публикации комментария, не обновляется форма -)
Николай, может стоит на главной странице или рядом с выбором языка, добавить ссылку на гит prinsma-cms? Ну и у вас "dfgfdg " болтается в левом нижнем углу.