Discourse_api sync_sso custom_fields приводит к "custom.custom.<field>" в payload

DiscourseApi::SingleSignOn ожидает, что пользовательские атрибуты будут назначены следующим образом:

sso.custom_fields['field_1'] = 'value'

# что приводит к ключу `custom.field_1` в полезной нагрузке

DiscourseApi::API::SSO.sync_sso() ожидает, что параметры будут иметь вид:

{ 'custom.field_1' => 'value' }

Однако она передаёт префикс custom. в sso.custom_fields.
В результате в полезной нагрузке появляется:

custom.custom.field_1

Также добавлены избыточные тесты для sync_sso.

1 лайк

На мой взгляд, это было бы намного проще, но не хочется ломать существующие приложения :grimacing:. Оставим генерацию экземпляра SSO на усмотрение пользователя.

# frozen_string_literal: true
module DiscourseApi
  module API
    module SSO
      def sync_sso(sso)
        post("/admin/users/sync_sso", sso.payload)
      end
    end
  end
end

Возможно, завтра я сделаю что-то вроде этого (но аккуратнее):

# frozen_string_literal: true
module DiscourseApi
  module API
    module SSO
      def sync_sso(params)
        if params.instance_of?(DiscourseApi::SingleSignOn)
          post("/admin/users/sync_sso", sso.payload) 
        elsif params.instance_of?(Hash)
          .... то же, что и сейчас
        end
      end
    end
  end
end

Что думаете? В идеале в моём приложении будет одна функция, генерирующая DiscourseApi::SingleSignOn, и тогда я смогу передавать её в sso_login или sync_sso.

Или параметры можно определить так:

{
  sso_secret: ...
  name: ...
  custom_fields: {
    field_1: ...
  }
}

Что тоже сломает существующие приложения.

2 лайка

Исправление для этого было внесено в прошлом месяце:

2 лайка