Роман, поясните мысль, пожалуйста. Например в ситуации, когда клиент не делал запросов за период времени ATLifetime < Tau < RTLifetime (человек не обновлял страницу, не нажимал кнопок и т.п.), как тогда следует поступать?
Dudder, когда клиенты с истекшим АТ получили 401, это значит что авторизация не прошла - и в методе с AllowAnonymous, если вы передаете токен, Identity.IsAuthenticated тоже будет false у юзера, т.к. время жизни токена истекло.
Как я поступал в подобной ситуации: на RefreshUrl отправляем модель с AT и RT, плюсом один из клеймов AT - SessionId.
Для разбора AT написан свой хелпер, который создает JwtTokenHandler с настройками, идентичными AddAuthentication, но с отключенной проверкой времени жизни токена.
В данной схеме RT - не JWT, а просто уникальный идентификатор, который при рефреше меняется - чтобы не получить два рабочих AT на сессию.
Как вариант можно сложить все нужные клеймы в RT (тоже JWT), тогда отправлять AT клиенты не должны вовсе, но свой TokenHandler для разбора RT и извлечения клеймов вам все равно понадобится.
Владимир Коротенко, а как это коррелирует с ответом (структура из нескольких форматов)? По описанию или ворд умеет скрин по запросу делать, или телега.
если можно поделитесь ссылкой на описание win32 api с такой работой с буфером обмена.
конвертировать на принимающей стороне не вариант? PNG для скринов при прочих равных обеспечивает лучшее качество, может винду можно "переучить", но не слышал о таком.
Владимир Кулеш, может, если сменили поношенный оригинал на откровенно плохой аккум.
но и оригинал за столько лет имхо мог убиться.
посмотреть: меню с яблоком, первый пункт при зажатом Alt (Информация о системе) или софт типа Coconut Battery.
Владимир Коротенко, в вопросе вроде про радиочастотные (из тех что встречал подключаются или по аналогу, или по оптике). IvanchikGLV уточните пожалуйста модель наушников, модель материнки и как именно они к ней подключены.
Komandarm, в netinst i386 32-битные UEFI загрузчики точно есть, только что качнул и проверил.
в полном и лайв аналогичных версий по-идее тоже должны быть.
брал ссылку тут
Komandarm, значит образ не UEFI, скачал первую попавшуюся убунту - она не UEFI действительно.
у debian есть i386 сборки с UEFI, попробуйте с них для начала загрузиться.
Владимир Шаблий, да, бывает экзотика. у меня разок было смешнее - API-шка чужая отдавала вроде бы нормальный json, но штатные десериализаторы им давились - пришлось писать минималочку чисто под этот кейс.
Что интересно потом апишку починили и костыль ушел в историю.
Владимир Шаблий, это по-моему эпический отказ, ибо каждый приличный сериализатор умеет в экранирование)
не, я вполне могу представить такой кейс - но это странно
Александр Андропов, string в base64 переводить большого смысла нет, base64 как раз придуман для того чтобы в изначально текстовых протоколах (rest, email и так далее) мочь передавать бинарные данные.
покажите доку на API, что и в каком формате вы ожидаете?
Задача странная - зашифрованная захардкоженная строка ничем особенным не отличается от логина и пароля (подсмотрели строку и ее используете для доступа к API) это если дешифровать сервером.
Если клиентом то значит ключ так или иначе должен быть на клиенте.
Может быть лучше зашить в сервер и клиент TLS (чтобы не только сервер предъявлял клиенту сертификат но и клиент серверу)?
Nulltiton, смотрите, у вас сейчас UI владеет всем, что в общем случае неверно.
для передачи данных между формами стоит использовать паттерны проектирования UI (MVC, MVVM и т.п.)
т.е. у вас например View оповещает контроллер, контроллер обновляет состояние модели, View (та же или совсем другая, не суть) обновляет на себе свойства, которые привязаны к модели.
По поводу сохранения: обычно архитектура такая, есть классы User (только свойства пользователя) и UserRepository, хранящий в себе CRUD операции над моделью (добавление, получение, удаление, изменение).
Если API у вас не анемичный (а предполагает те или иные логические действия и проверки) то выделяете еще один слой. Один из основных критериев готовности архитектуры к развитию - вы можете любой слой заменить другим (при условии совместимости интерфейсов) и у вас ничего не сломается.
Такой подход называется "луковая архитектура" - каждый слой взаимодействует только с двумя соседними.
Портятся данные вот к чему - статическое поле является общим для всех экземпляров класса, поэтому статические поля в нестатических классах надо применять хорошо понимая зачем именно вы этого хотите.
Form2, button1 - зло, в большом приложении будет Form18, button138 - как будете поддерживать?
В дизайнере можно раздать нормальных названий (MainForm, UserAddDialog, etc)
Мешать логику с обработчиками кнопок - зло, завтра UI будет другой.
Мешать DTO c сохранением данных - зло, завтра будет другая база, API или вообще файлы.
DTO для хранения данных и для обработки клиентом строго говоря не равны друг-другу.
static'и следует юзать понимая что это и зачем - в примере вы откроете 2ой экземпляр форм_1 и не будете понимать почему у вас данные портятся.