Как разграничить доступ пользователей к web ресурсам?
Вечер добрый!
Имеется web-приложение, в которое входит api, например, оно доступно по localhost/api
Имеется 2 вида пользователей user1 и user2, которые должны видеть разные ресурсы, например localhost/app1 и localhost/app2, работа которых сводится к выполнению ajax запросов к api. Приложения app1 и app2 используют исключительно html+css+js, api написано на php
Подскажите, пожалуйста, каким образом можно более правильно разграничить доступ так, чтобы user1 мог ходить на app1 и при попадании на app2 получал сообщение, типа "нет доступа". То же самое и со вторым: user2 - app2
Единственное решение, которое я могу предположить - это на каждой странице с помощью js отправлять запрос на возможность доступа пользователя к ресурсу, но мне кажется, что это решение громоздкое.
Понимаю, что на user1 в app2 может увидеть только структуру страницы, но не данные (т.к. данные разграничены по api_token), но хотелось бы чтобы он и этого не видел.
Не уверен что понял правильно ваш вопрос, но мне кажется правильным будет следующий вариант:
user1 и user2 обращаются на один и тот же api урл - /api
при обращении, в заголовке они передают версию api.. например так:
для user1 Accept: application/json; version=1.1;
для user2 Accept: application/json; version=1.2;
На бекенде, в роутинге, мы смотрим на какую версию апи пришло обращение. Если на версию такуюто, то подгружаем такоето апи, на версию сякуюто - сякуюто версию апи.
Да, Вы не совсем поняли вопрос. Доступ к ресурсам api уже разграничен, он отдает пользователям только те данные, которые они могу видеть.
Вопрос именно в том, чтобы user1 при попытке попасть на app2 получал ответ, типа "страницы не существует" или "нет доступа".
Т.е. каждый пользователь авторизуется в своем экземпляре приложения: user1-app1, user2-app2.
Нужно, чтобы user2 ничего не знал про app1, не мог посмотреть даже каркас странички.
vkoshelev_01,
так епт ) как он посмотрит если апи должно выдать 403 ошибку?
Давай разберем по полочкам.
При любом обращении к API, пользователь передает token, не важно какой.. jwt token или обычный access token. Миддлваре или какойто колбек по типу before_action вашего API должен авторизовать вашего пользователя через полученный токен, т.е. это должно происходить ДО срабатывания того или иного экшна контроллера того или иного апи. И если авторизация не прошла, апи должно выдать ошибку 403.
Я же писал выше, что данные на страницу app2 никакие не попадут - user1 не будет иметь прав на их просмотр. Api отдаст 403.
Но thml+js-то отработается и пользователь увидит страничку, но без контента) Ну как без контента - структура страницы, меню.
Вопрос в том, что даже это он не смог увидеть.
Судя по всему, нужно смотреть обработчики js, которые выполняются до события $( document ).ready() и там проверять наличие прав на просмотр. Если нет - менять document.location
И самая проблема в том, что чтобы проверить доступ к какой-либо страничке, нужно отправить запрос к api.
И мне кажется, что это будет накладно, т.к. этот механизм будет работать и при серфингу по страницам доступного ресурса. Например, чтобы user1 смог посмотреть страницы на app1, при каждом переходе будет выполняться запрос на наличие доступа к этой странице.
Это напрягает.
vkoshelev_01, Я не знаю на чем писан у вас фронтенд.. Я использую reactjs у себя на react-router v4 в паре с jwt токеном.
Благодаря JWT токену, я вижу роль юзера, и разделяю фронтенд-роуты исходя из роли. Т.е. создаю приватный роутинг. В моем случае это разделение между юзер панелью и админ панелью.
Stalker_RED, нет, все права проверятся на сервере. На клиенте всего лишь хочу ограничить доступ к просмотру структуры страницы рядовому пользователю. (Меньше знает - лучше спит) Тот кто хочет - докопается до структуры, но данных там все равно не будет (отдаются на сервере по правам).
Появилась еще идея делать следующим образом: при авторизации user1 получает api_token и ссылку на доступный ресурс и соединяет с текущим хостом, например location.host + '/app1'
И перед загрузкой каждой страницы делает проверку адреса страницы на соответствие маске location.host + '/app1'. Если маска не верна - делает редирект на страницу 404.html
Таким образом user1 не сможет попасть на app2
Это дешевле чем перед выполнением каждой страницы делать запрос к api на проверку доступа к странице.
Картина следующая.. У тебя фронтенд отделен от бекенда. И фронтенд стучит на разное апи бекенда для тех или иных юзеров. Для общего понимания будем считать что разделение происходит между админ панелью и обычным юзером. И проблема в том, что верстка админки присутствует во фронтенде, но её нужно скрывать так? По идее да.
Все запросы на апи происходят средством xhr, тобишь в фоне, и если какойто очкарик начнет ковырять - то он хоть и не получит данные с бекенда, но увидит верстку, разделы все и тд итп. И ты этого хочешь избежать.
Если все так как я описал, то чтобы ты не делал, ты должен понимать что весь контент ты уже отдал юзеру, и если очкарик не зря носит свои очки, он все расковыряет и всё узреет, и никакие редиректы тебя не спасут.
Если я гдето не правильно чтото изложил, то будет лучше если ты приведешь технологии которыми пользуешься во фронтенде, и представишь картину более детально, ибо трудно по звездам гадать.
Shaks ну тут вопрос лишь в том, чтобы простой пользователь user1 не мог посмотреть, чего там на app2. Как бы он все равно ничего сделать, не сможет, но хотелось бы просто оградить на начальной стадии - любопытства.
Ну и чтобы администратор не нервничал, что кто-то может видеть страницу чужую) Пусть и без данных
