А что дальше? Ну вот склонировал репозиторий и затем понадобилось внести изменения туда, куда склонировал. Например, добавить логику в action. Ну и оригинальный компонент затер.
Или что вы имеете ввиду?
Мне нужно, чтобы я мог не модифицировать установленное приложение, и вносить изменения в новое приложение.
К примеру, добавил компонент /src/app/dashboard/page.tsx
И он отрабатывает по этому маршруту. Иначе если его нет, то отрабатывает маршрут из установленного приложения MyReactjsAppFromNPm
Ну в общем я так и начал сначала делать.
То есть чтобы добраться до строк из Variable_values нужно присоединить Template_variables, затем Variables и затем только Variable_values. Если сразу приджойнить таблицу Variable_values, то есть вероятность, что мы заберём те строки из Variables, которых нет в строках Template_variables.
Но такое количество джойнов, даже с LIMIT 10 выходит очень медленно. Либо я что-то не так делаю. Делаю везде LEFT JOIN.
Алексей Горбунов, рекурсия поможет найти 3 уровня вложенности таблицы Resources (это можно сделать и джойнами, рекурсия лусше?). А как правильно присоединить к уже выбранным строкам из Resources строки из таблиц Variables и Variable_values? Или я не правильно Вас понял?
Я правильно понимаю, что Ваш метод отличается от jwt тем, что там подпись основывается на хэше заголовка и полезной нагрузки, а у Вас на хэше fingerprint'а?
Вопросы по пунктам:
1)
отпечаток клиента (fingerprint)
Fingerprint получается с помощью какой-то js библиотеки? Что бы Вы посоветовали?
шифруется парольным хешем пользователя
Пароль берём из формы аутентификации, куда пользователь его вводит, получаем его хэш (любой функцией?) и с его помощью шифруем (чем лучше шифровать?) fingerprint, верно?
Все операции первого пункта происходят на клиенте? Видимо, с помощью какой-то js библиотеки?
2)
Сервер открывает своим приватным ключом пакет
Имеется ввиду, расшифровывает тем же публичным ключом, что пользователь зашифровывал?
Юзерагент/ip подделывается.
А, если установить для cookie HttpOnly, это поможет от считывания их через js, верно? Какими средствами для защиты пользовательских данных Вы пользуетесь?
FanatPHP, выше ThunderCat привёл пару примеров кражи токена: "действия третьих лиц, например левых плагинов в браузере, вирусов". И ThunderCat верно заметил, что это будет вина пользователя. Вопрос, можно ли в этом случае 100% понять, что этот краденый (но ещё валидный токен) используется не тем, кому он выписан?
Сессии не устраивают сроком жизни.
ThunderCat, проблема может быть в получении доступа к персональным данным пользователей третьими лицами.
Я не профессионал, а Вы, надеюсь, да. Вот у Вас и спрашиваю. С задачей написания личного кабинета раньше не сталкивался. В руки попадались сайты с уже написанным кабинетом, и все были на сессиях. Сейчас нужно хранить аутентифицированного пользователя дольше, чем время жизни сессии. Начал изучать вопрос, и оказалось, что jwt - хороший вариант, за исключением того, что токен могут увести. Это гугление, а не мои придумки. Таких тем как эта полно. Но так и не нашёл полностью безопасный способ аутентификации пользователя.
Евгений Ромашкан, разобрался. Вы правы, моё сравнение с сессией неудачное. Тогда вопрос сводится к тому, можно ли на 100% точно определить угнан или нет токен, пришедший от клиента (не важно хранится он у него в cookies или ls)?
Хотелось бы, чтобы на стороне клиента нельзя было подделать данные (например, токен). Jwt украли и всё тут. Да, можно с вместе токеном хранить на сервере юзер агент и прочее, но это тоже подделывается.
Действительно, это хороший вариант.
Убрал из массива пользователей ссылки на подключённые соединения. Вместо этого добавил в $connection->user_id id авторизованного пользователя (если такой есть).
Спасибо!