Частая ротация - это да, но по поводу хранения их именно в куки мне кажется оверхедом.
1. Если кто-то другой получит ваш токен. Чтобы получить access token, нужно скопировать его вручную из local storage браузера, если у потенциального "хакера" есть такого уровня доступ к пользовательской машине, то скорее всего уже ничего не поможет.
2. Если пользователь сам передаст кому-то токен. Ему также ничто не мешает самостоятельно передать свои логин и пароль.
3. Перехват заголовков. Что с токенами, что с куки есть своих защитные механизмы
Мне кажется, более важно грамотно настроить политики доступа, чтобы, например, рядовой пользователь мог вызывать только разрешённые ему действия. Тогда он никак не грохнет систему. Его токен будет обладать только минимальными правами. А за утечку логина и пароля отвечает в том числе сам пользователь.
Figment, имел ввиду, что в случае с куки, мы получаем их на клиенте, и в то же время они хранятся и на сервере, когда мы шлём запрос, то сервер сверяет куки с тем значением, которое там хранится.
Упрощённый пример сценария
1. Пользователь в роли А отправил сообщение пользователю в роли Б, это сообщение показываются у Б в виде попапа с кнопкой
2. Пользователь в роли Б увидел попап и нажал на кнопку, в этот момент обновляется состояние пользователя роли С. Теперь Пользователь в роли С может сделать некоторое действие.
3. Пользователь в роли С выполняет действие, это действие вызывает сторонний апи. Состояние системы обновится, когда этот сторонний апи, вызовет вебхук.
4. Пользователь в роли Д за всем наблюдает, и иногда можно редактировать процессы.
Таких ролей 6 штук. Чтобы что-то делать пользователь должен авторизоваться. Каждый раз разлогиниваться, залогиниваться не удобно. Т.к. токен хранится в Local storage, который шарится между всеми вкладками, в одном окне может быть только один пользователь. Вот и получается 6 окон.
Dmitry Bay хочется чего-то простого и максимально расширяемого и кроссплатформенного. С sql - захотел новую таблицу, или характеристику, или новый срез данных - добавил) Решение заточенное именно под меня и доступно с любого устройства при наличии sql клиента.
Зачем формы и списки? В принципе, каталогизатор - это частный случай клиента к БД. Мне быстрее напрямую работать с БД, чем придерживаться рамок чужого приложения или поддерживать своё приложение.
Конкретно в данном контроллере к данному экшену защита отсутствует. ЛОЛ :) Защита осуществляется с помощью аттрибута Authorize, а на экшене поставлен AllowAnonymous. Скорее всего это было сделано, чтобы разрешить запрос при window.open(url, '_blank').
Спасибо, теперь, когда понял, что инфа автоматически добавляется в headers и летает между сервером и SPA, картинка окончательно сложилась. AuthApi - выполняет аутентификацию и отдаёт токены, остальные api просто используют UseOAuthBearerAuthentication, т.е. токен в SPA полученный из AuthApi отправляется во все другие Api, а они просто распаршивают его и получают CurrentUser.
-----------------------------------------------------------------------------------------
Нашёл проблему. Дело в том, что страница, которая использует контроллер в WebApi открывается с помощью метода window.open(url, '_blank'); В этом случае заголовки не добавляются и поэтому у запроса к WebApi не установлен BearerToken, соответственно WebApi расценивает это как CurrentUser раный null.
Я неправильно выразился нужна технология. Первое что нашёл - это рисование на bitmap, причём bitmap у меня в picture box засунул :) Основной вопрос - это кликабельность нарисованной фигуры, чтобы можно выделить. С pitcturebox - поставил события на клик вот и выделение.
1. Если кто-то другой получит ваш токен. Чтобы получить access token, нужно скопировать его вручную из local storage браузера, если у потенциального "хакера" есть такого уровня доступ к пользовательской машине, то скорее всего уже ничего не поможет.
2. Если пользователь сам передаст кому-то токен. Ему также ничто не мешает самостоятельно передать свои логин и пароль.
3. Перехват заголовков. Что с токенами, что с куки есть своих защитные механизмы
Мне кажется, более важно грамотно настроить политики доступа, чтобы, например, рядовой пользователь мог вызывать только разрешённые ему действия. Тогда он никак не грохнет систему. Его токен будет обладать только минимальными правами. А за утечку логина и пароля отвечает в том числе сам пользователь.