Помогите разобраться вот в чем - если у нас SPA, то получается мы отдаем один js-файл и отрисовываем страницу уже на клиенте по нужным нам сценариям, но вот вопрос, получается даже не авторизованный пользователь сможет просмотреть весь наш, например main.js и узнать, например, на какие url мы делаем запросы за данными. Понятно что без авторизации данные от API он не получит, но будет знать структуру нашего API? Или не так? Буду благодарен ссылкам на статьи (можно и на англ) о том как реализуется авторизация в настоящих (не образцов для туториалов) SPA приложениях.
PS: Для бекенда используется django-rest-framework
Ну например в случае обычного сайта, например на джанго. Я, не авторизованный пользователь буду переадресован на страницу логина - я не знаю какие еще урлы есть на сайте, например /users/, /accounts// и т.п.
В случае SPA мне также откроется страница с формой для логина, но т.к. у нас одностраничное приложение то в нашем js-файле есть например такая строчка (взял из проекта для одного из туториалов на гитхабе)
Таким образом, мы даем понять потенциальному злоумышленнику на каком IP находится наше API и какие есть эндпоинты.
Возможно, у меня просто паранойя, и это все не имеет значения...
Т.е. я хочу сказать, что если я не хочу давать неавторизованным пользователем вообще никакой лишней информации, как мне лучше поступить?
Алексей Ярков, Просто привык мыслить так, что чем меньше пользователь знает тем лучше) Конкретно по эндпоинтам в некоторых случаях можно сделать вывод о том какие роли присутствуют в системе. Ну да ладно, spa стал изучать только недавно и мне просто было интересно, нормальный ли это подход, или это только в туториалах так делают, а на реальных проектах есть какието свои способы специальные...
tvsjke, это примерно то же что и на все роуты один айпишник. только найти проще, выглядеть будет красивше, потенциальный "хакер" будет благодарен.
V-ampre, подход нормальный, защищаются от конкретных рисков, "привык мыслить" к реальным проектам мало имеет отношения, это просто паранойя. Хотите чтобы пользователь ничего не знал - удалите свой сайт, способ 100%. Все остальное требует разумного подхода.
Хотите защищаться - проанализируйте возможные векторы атаки, вероятность их осуществления и потенциальный вред. После этого думайте что и где поменять-защитить. Может у вас и нет их, проблем настоящих.
Если у вас реальный риск утечки информации о том какие роли есть в системе, и это может принести реальный вред - то переделывайте систему так чтобы в урлах этой информации не было. Но практически наверняка она будет в коде в другом виде все равно.
Я бы посоветовал отталкиваться от следующей концепции:
1. фронт у вас должен отвечать только за визуализацию - все чувствительные данные отдаются бэком и туда же возвращаются. Вам должно быть реально всё равно, что ваш js смогут распарсить, без авторизации нет смысла. Так же если вы желаете прикрыть какой-то суперуникальный код на фронте - сборщики с обфускацией, прочая фигня ))
2. Авторизацию можно делать по схеме jwt-токена с выпуском короткоживущего токена, которым подписываются запросы в бэк, к нему рефреш токен для обновления. Токены можно хранить в локалсторе, чтобы выгрузка браузера не потерла состояние авторизованности. Примеров в интернете должно быть полно. Время жизни токенов выбираете на свой вкус.
Как лучше токен для обновления сделать? Я пологаю сгенерировать точно такой же токен, но на более долгое время и сунуть его в http only куку (чтоб никакой чужой код на клиенте при всём желании не смог получить доступ к нему)? При разлогинивании соответственно удаляем все токены (и короткоживущий, и токен для обновления).
Токен для обновления не обязательно должен быть таким же сложным как основной. Им никакие запросы не подписываются.
Хранить можно в куках, можно в локалсторе, не принципиально.
В плане реализации можно посмотреть как делают на oAuth например.
На самом деле мне тоже это не нравится. Этот вопрос я решил довольно просто. Отдельная страница авторизации, и уже ПОСЛЕ успешной авторизации загрузка SPA. Тут пишут типа в чём проблема? Ну так-то DDOS никто не отменял. Авторизация может проходить через один сервер, а работа с АПИ через другой. Дабы закрыть апи от внешнего мира.
Простой
