Исследуйте наше августовское обновление 2024 года, включающее подмену пользователя, управление секретами приложений, брендинг на уровне организации и приложения при входе, и многое другое.
Добавлена поддержка подмены пользователя через Обмен Токенами:
POST /subject-tokens для запроса subject_token для использования в обмене токенов.POST /oidc/token с новым типом гранта urn:ietf:params:oauth:grant-type:token-exchange для обмена subject_token на access_token для подменённого пользователя.Смотрите Подмена пользователя для получения дополнительных сведений.
custom_data на уровне приложенияДобавлено новое произвольное объектное поле custom_data для приложений. Это поле может хранить любую дополнительную информацию, не определённую в стандартной схеме Application.
PATCH /api/applications/{applicationId}/custom-data для частичного обновления поля custom_data приложения.PATCH /api/applications/{applicationId} для возможности перезаписи поля custom_data.Добавлен новый JSON-редактор для пользовательских данных на странице сведений о приложении (за исключением защищённых приложений).
Защищённые приложения (машина-машина, традиционные веб, защищённые) теперь могут иметь несколько секретов приложений с истечением срока действия. Это позволяет выполнять ротацию секретов и обеспечивает ещё более безопасный опыт.
Примечание: Старые секреты, созданные до этой функции, всё ещё могут использоваться для аутентификации клиента. Однако рекомендуется удалить старые секреты и создать новые с истечением срока действия для усиления безопасности.
GET /api/applications/{applicationId}/secrets: Перечислить все секреты приложения.POST /api/applications/{applicationId}/secrets: Создать новый секрет для приложения.DELETE /api/applications/{applicationId}/secrets/{name}: Удалить секрет приложения по имени.PATCH /api/applications/{applicationId}/secrets/{name}: Обновить секрет приложения по имени.DELETE /api/applications/{applicationId}/legacy-secret: Удалить старый секрет приложения и заменить его новым.Для управления секретами приложения перейдите в Logto Консоль -> Приложения -> Сведения о приложении -> Конечные пункты и Учётные данные.
Поле для ввода старого секрета приложения теперь заменено на новую таблицу управления секретами. В этой таблице можно создавать, обновлять и удалять секреты.
Теперь можно установить светлые и тёмные логотипы для организаций. Вы можете загрузить логотипы на странице настроек организации.
Также можно переопределить логотип для входа, установив логотип организации. Просто добавьте параметр organization_id в запрос аутентификации. В большинстве SDK Logto это можно сделать, используя поле extraParams в методе signIn.
Например, в JavaScript SDK:
Значение <organization-id> можно найти на странице настроек организации.
Если вы не нашли поле extraParams в используемом вами SDK, пожалуйста, дайте нам знать.
Теперь вы можете установить логотипы, фавиконы и цвета для вашего приложения. Эти настройки будут использоваться в процессе входа, когда приложение инициирует аутентификационный процесс. Если для приложения не заданы настройки брендинга, будет использоваться общий брендинг для процесса входа.
Если в запросе аутентификации указан параметр organization_id, настройки брендинга на уровне приложения будут переопределены настройками брендинга организации, если они доступны.
Logto теперь внедряет настройки и фразы для процесса входа непосредственно в файл index.html для повышения производительности первой загрузки экрана. Приложение всё ещё будет запрашивать настройки и фразы с сервера, если:
tsup для сборки пакетов коннекторов. Это ускорит процесс сборки и не должно влиять на функциональность пакетов.Vite для транспиляции и сборки пакетов @logto/console, @logto/demo-app и @logto/experience. ParcelJS был удалён и заменён на Vite. Серьёзные изменения быть не должны.PATCH /api/applications/{applicationId}Все поля jsonb объекта Application теперь должны обновляться в режиме replace вместо merge. Это изменение сделает метод PATCH более предсказуемым и согласованным с проектированием RESTful API.
merge на replace в конечном пункте PATCH /api/applications/{applicationId}.PATCH /api/applications/{applicationId} с partial на full.oidc_client_metadata, custom_client_metadata, protected_app_metadata и custom_data.Примечание: Если вы используете консоль Logto для обновления настроек
Application, это изменение не должно вас затронуть. Пользователям API, использующим методPATCHдля обновления настроек jsonb поля приложения, следует учитывать это изменение. МетодPATCHтеперь будет заменять всё поле jsonb новыми данными. Любые частичные данные для затронутых полей будут отклонены.
Затронутые события вебхуков: Role.Scopes.Updated, Organizations.Membership.Updates.
Статус API, возвращаемый из вебхука, всегда был 404. Это было вызвано вставкой данных перед установкой контекста API ответа.
Поскольку вебхук срабатывает только при успешной обработке события, статус ответа должен всегда быть 2xx.
Эта проблема была исправлена путём перемещения вставки данных вебхука после установки контекста API ответа.
Argon2d и Argon2id. Пользователей с этими алгоритмами переведут на Argon2i при успешном входе.@logto/experience синхронизирована с тем, что указано в README.md.