Когда знаешь, что тебе нужно, а еще и ревьюишь сгенереный код после каждой итерации, то очень велика вероятность, что все получится. Сам так же делаю. А иногда прошу объяснить методы существующего кода, когда с наскоку непонятно, что происходит.
А у меня обратная ситуация была: из ТБанка постоянно были спам звонки и спрашивали я ли это? Я отвечал, что я - это не я. Однажды я все-таки решил зайти в приложение ТБанка (там у меня нет карт). И не смог. Пришлось заново привязывать свой номер телефона, но в поддержке мне так и не сказали, почему вдруг "отвалился" мой номер телефона :)
для меня тоже интересен вариант, когда ресурсов тысячи. Но, как я понял, ресурсы можно в токен дописывать. Допустим, штук 50, мне кажется, в токене будет ненапряжно таскать. В общем, прочитайте, тут найдете ответы на все вопросы https://www.keycloak.org/docs/latest/authorization_services/index.html. Пока я целиком не прочитал, рабочего варианта получить не мог.
Тут вступает в силу UMA. Вы с токеном с публичного клиента идете в бек, бек идет в keycloak с запросом ресурса, получает permission ticket и возвращает его на фронт. Фронт берет тикет и обменивает его на новый токен, уже RPT. И уже с этим RPT идет на бек.
Возможно вы имели в виду то же самое. Но тогда я не понимаю, чего там сломано. Прямо сейчас делаю эту процедуру в Keycloak 26.
Лучше напишите какую-нибудь достаточно серьезную статью. С базовыми настройками любой разберется. Либо предложите какое-нибудь неочевидное решение. Или как вы решаете проблему доступа к конкретным ресурсам, допустим, их у вас тысячи. Таскаете ли вы их все в RPT или у вас там только последние N штук. А сколько N штук лучше всего хранить в токене?
Фронт нужен только лишь для того, чтобы обращаться к своему ресурс серверу с передачей RPT (requesting party token). Тут и появляется главное предназначение keycloak - UMA (user managed access). Использование Keycloak в качестве authorization server - это, по моему, больше вспомогательная роль. Т.к. наверняка на рынке есть куча подобных решений.
Одной из отличительных особенностей заключается, в том что в OpenID Connect, добавляется дополнительный шаг в работе алгоритма. Когда вместо access token, сначала провайдер SSO возвращает клиенту code. В обмен на который у провайдера SSO клиент получается access token.
Этот шаг всегда был в старом добром OAuth 2.0.
Кроме приведенных вами трёх Authorization Flow есть как минимум еще один, довольно интересный: Direct Access Grant flow. Это когда мы в провайдер ПОСТ запросом можем отправить user credentials (username, password), а получить access token.
А еще для мобильных клиентов, десктопных клиентов и SPA есть Authorization Code Flow with PKCE.
а если учесть, что диспетчер тоже обращается к ОС, чтоб та выделила память, то еще интереснее получается: просто смотрим на скорость быстродействия диспетчера в вакууме.
Когда знаешь, что тебе нужно, а еще и ревьюишь сгенереный код после каждой итерации, то очень велика вероятность, что все получится. Сам так же делаю. А иногда прошу объяснить методы существующего кода, когда с наскоку непонятно, что происходит.
открыл ссылку с геолокацией в десктоп тг, и открылись карты МС.
важное уточнение: открыть файл с правами администратора, а то не сохранится.
из-за сахара
Приветствую, когда ждать новых статей?
А у меня обратная ситуация была: из ТБанка постоянно были спам звонки и спрашивали я ли это? Я отвечал, что я - это не я. Однажды я все-таки решил зайти в приложение ТБанка (там у меня нет карт). И не смог. Пришлось заново привязывать свой номер телефона, но в поддержке мне так и не сказали, почему вдруг "отвалился" мой номер телефона :)
Посмотрел видео одного уважаемого канала, там показали, что карточки старшего поколения уже Out of Stock.
для меня тоже интересен вариант, когда ресурсов тысячи. Но, как я понял, ресурсы можно в токен дописывать. Допустим, штук 50, мне кажется, в токене будет ненапряжно таскать. В общем, прочитайте, тут найдете ответы на все вопросы https://www.keycloak.org/docs/latest/authorization_services/index.html. Пока я целиком не прочитал, рабочего варианта получить не мог.
не стоит полагаться на чатгпт в вопросе keycloak, многое приходится делать по-другому.
Тут вступает в силу UMA. Вы с токеном с публичного клиента идете в бек, бек идет в keycloak с запросом ресурса, получает permission ticket и возвращает его на фронт. Фронт берет тикет и обменивает его на новый токен, уже RPT. И уже с этим RPT идет на бек.
Возможно вы имели в виду то же самое. Но тогда я не понимаю, чего там сломано. Прямо сейчас делаю эту процедуру в Keycloak 26.
Лучше напишите какую-нибудь достаточно серьезную статью. С базовыми настройками любой разберется. Либо предложите какое-нибудь неочевидное решение. Или как вы решаете проблему доступа к конкретным ресурсам, допустим, их у вас тысячи. Таскаете ли вы их все в RPT или у вас там только последние N штук. А сколько N штук лучше всего хранить в токене?
Все, что касается этой статьи, описано тут https://www.keycloak.org/docs/latest/authorization_services/index.html.
Фронт нужен только лишь для того, чтобы обращаться к своему ресурс серверу с передачей RPT (requesting party token). Тут и появляется главное предназначение keycloak - UMA (user managed access). Использование Keycloak в качестве authorization server - это, по моему, больше вспомогательная роль. Т.к. наверняка на рынке есть куча подобных решений.
Два критических заменчания:
Этот шаг всегда был в старом добром OAuth 2.0.
Кроме приведенных вами трёх Authorization Flow есть как минимум еще один, довольно интересный: Direct Access Grant flow. Это когда мы в провайдер ПОСТ запросом можем отправить user credentials (username, password), а получить access token.
А еще для мобильных клиентов, десктопных клиентов и SPA есть Authorization Code Flow with PKCE.
я больше склоняюсь к тому, что в определенное время транслитерировали так, а потом стали эдак. Это мои догадки, я в них не уверен.
с тех пор наверное и ситемы хранения информации поменялись с HDD на SSD.
а как же доктор Ватсон?
а если учесть, что диспетчер тоже обращается к ОС, чтоб та выделила память, то еще интереснее получается: просто смотрим на скорость быстродействия диспетчера в вакууме.
а у меня порезали до 15ГБ.
https://www.engadget.com/2015-11-02-microsoft-is-cutting-off-unlimited-onedrive.html