Я занимаюсь логической безопасностью на основе информации о текущем пользователе, например, проверяю условие: «если имя создателя темы равно имени текущего пользователя», то разрешаю пользователю редактировать тему или удалять её.
Суть в том, что мне нужно гарантировать выполнение определённых действий на основе сессии пользователя! Но я провёл несколько тестов, и именно поэтому я здесь и спрашиваю вас.
Через JavaScript в веб-браузере (даже в режиме production) я могу выполнить Discourse.User.current().set(‘username’, ‘sometestename’). Таким образом, некоторые действия в моей системе будут разрешены только благодаря этому изменению. Я понимаю, что это не цель 99% пользователей, но в данном случае вы, ребята, знаете способ убедиться, что пользователь не сможет манипулировать информацией о себе?
Если вы измените информацию в своём локальном браузере, это никак не повлияет на бэкенд.
Пользователь входит в систему с помощью токена аутентификации, насколько я понимаю, поэтому вы не сможете выдать себя за другого пользователя на стороне бэкенда:
Поскольку обмануть сервер невозможно, вы не сможете внести какие-либо изменения от имени другого пользователя.
Как только вы обновите браузер, ваши локальные изменения, скорее всего, будут удалены. В худшем случае вы можете нарушить состояние приложения на JavaScript, и вам придётся очистить кэш.
Как вы и сказали, лучший способ — всегда получать текущую сессию пользователя с бэкенд-сервера.
Так изменения кэша в браузере не смогут повлиять на ситуацию! Не знаете, где можно проверить, что логическая безопасность основана на сессии пользователя с бэкенд-сервера, а не на PreloadStore?
Предупредите, если я иду неверным путём! Спасибо за помощь, Роберт!
Я не эксперт по безопасности, а лишь разработчик приложений, но все постоянные изменения могут быть внесены только на сервере. То, что происходит в браузере в EmberJS, предназначено для удобства пользователя и улучшения пользовательского опыта, например, кэширование для ускорения работы и автоматическое поведение интерфейса, похожего на приложение. Это не меняет того факта, что в конечном итоге все постоянные изменения должны быть согласованы с сервером Rails, и при этом у пользователя есть разрешение на их внесение только для авторизованного пользователя.
То же самое касается всех операций извлечения данных — сервер Rails будет отправлять только те данные, к которым имеет доступ авторизованный пользователь.
Я не думаю, что вам стоит об этом беспокоиться, потому что если кто-то попытается обойти эту защиту, он столкнется с первым препятствием: обмануть API невозможно.
Меня беспокоит тот факт, что в некоторых подходах возможность выполнения такого действия зависит от пользователя: является ли он создателем темы или создателем сообщения. Поэтому мне необходимо проводить валидацию на основе сессии пользователя на стороне сервера.
Например, пользователь может редактировать сообщение, только если он является его создателем.
РЕДАКТИРОВАНИЕ: Я изучу это, ориентируясь на права доступа к сообщениям в Discourse.
