Как правильно реализовать админ-панель в SPA?

Question

[flafy4]

Всем привет. Как правильно реализовывать какой либо административный функционал в SPA? Сейчас говорю про классическую dashboard. Если сделать просто защищенные роуты типа - example.com/admin с защитой, то это не совсем правильно как я понимаю ибо можно открыть в конце концов build.js и увидеть там статический HTML на всех этих "защищенных аутентификацией и правами пользователей" страницах. Возникает очевидное решение - делать такие админки на отдельных доменах, ибо все равно весь функционал и взаимодействия с БД осуществляются с помощью RESTfull API. Но есть ли другой способ, и как делаете это вы?

Comments

[Interface]

Подгружать админ. бандл только в случае необходимости?

[lamer350]

или ограничить доступ по IP к папке админ, в остальных случая отдавать роут 404. Никто и не узнает что адрес рабочий...

[flafy4]

Егор Скороходов, А вы считаете ничего страшного в этом нет? Например там могут быть статические пути, а точней они там и будут по другому никак. Возьмем пример со страницей службы поддержки. И там есть поле ответа на тикет и кнопка отправить. На кнопке повешан url example.com/admin/tickets/111/save. Любой уже знает что у нас есть путь example.com/admin

[flafy4]

Егор Скороходов, Да даже просто меню, admin/dash, admin/tickets, admin/moderation и т.п.

Answer 1

[sim3x]

Как правильно реализовывать какой либо административный функционал в SPA?

в вебе у вас один (простой*) вариант знать, что запрос пришел от авторизированного пользователя - куки

*сложные и не всегда рабочие смотрите в коментах

Если сделать просто защищенные роуты типа - example.com/admin с защитой, то это не совсем правильно как я понимаю ибо можно открыть в конце концов build.js и увидеть там статический HTML на всех этих "защищенных аутентификацией и правами пользователей" страницах.

и правильно. Перед тем как процессить запрос в апи проверяются права пользователя

Возникает очевидное решение - делать такие админки на отдельных доменах, ибо все равно весь функционал и взаимодействия с БД осуществляются с помощью RESTfull API.

отдельный домен делается для того, чтоб куки не утекали, если пользователям позволено вставлять жс код

Comments

[sim3x]

Егор Скороходов, http is stateless protocol

[sim3x]

Егор Скороходов, и в каком фреймворке сейчас данные заголовки используются для авторизации?

И как оно вообще открыто оперировать имнем:паролем пользователя вместо токена?

[sim3x]

Егор Скороходов,

а с чем-то, у чего вообще куки нет, как по вашему должны клиентов авторизовывать?

токен в параметрах, тк там не произойдет неожиданного кеширования на клиенте

вы тактично соскочили

видимо стоило добавить слово "нормальный", а то вы ведь точно предложите вебсокет использовать для целей авторизации

ну например jwt-бандл для симфони

Осталось только пройтись по всем корпоративным проксям и пояснить, что некоторые заголовки стоит оставить, тк про куки мы не в курсе
Да

Answer 2

[0xD34F]

можно открыть в конце концов build.js и увидеть там...

Да плевать. Главное, чтобы ваш бэкенд не позволял делать лишнего пользователям с недостаточными правами.

Другое дело что загружать код, который заведомо не должен исполняться - излишне, так что имеет смысл разбить ваш build.js на несколько частей.

Comments

[flafy4]

Очень во-время я нашел очень замечательную вещь в Vue.JS - ленивая загрузка. Как раз то что Вы и имеете в виду.