Ошибка Geode / GemFire ​​/ P CC - учетные данные безопасности не предоставляются - PullRequest
0 голосов
/ 09 апреля 2020

У меня есть приложение Springboot, размещенное на PCF, которое пытается подключиться к P CC (основной облачный кеш). Я раскрутил экземпляр P CC, связал его с моим приложением и перенес приложение в облако dry. Я добавил все необходимые зависимости для запуска gemfire в springboot, и похоже, что он смог прочитать информацию о локаторе и сервере из VCAP_SERVICES. Но я вижу следующую ошибку при запуске приложения весенней загрузки.

Error prefilling connections : org.apache.geode.security.AuthenticationRequiredException: No security credentials are provided
org.apache.geode.security.AuthenticationRequiredException: No security credentials are provided
at org.apache.geode.internal.cache.tier.sockets.Handshake.readMessage(Handshake.java:320)


Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache.geode.cache.Region]: Failed to create Region for cache [TestRegion]; nested exception is org.apache.geode.security.AuthenticationRequiredException: No security credentials are provided

Вот мой список зависимостей

        <dependency>
            <groupId>org.springframework.geode</groupId>
            <artifactId>spring-gemfire-starter</artifactId>
            <version>1.2.6.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.data</groupId>
            <artifactId>spring-data-gemfire</artifactId>
            <version>2.2.1.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>javax.cache</groupId>
            <artifactId>cache-api</artifactId>
            <scope>compile</scope>
        </dependency>

        <dependency>
            <groupId>io.pivotal.gemfire</groupId>
            <artifactId>geode-core</artifactId>
            <version>9.5.4</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>io.pivotal.gemfire</groupId>
            <artifactId>geode-common</artifactId>
            <version>9.5.4</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>io.pivotal.gemfire</groupId>
            <artifactId>geode-cq</artifactId>
            <version>9.5.4</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>io.pivotal.gemfire</groupId>
            <artifactId>geode-lucene</artifactId>
            <version>9.5.4</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>io.pivotal.gemfire</groupId>
            <artifactId>geode-wan</artifactId>
            <version>9.5.4</version>
            <scope>compile</scope>
        </dependency>
@Configuration
@ClientCacheApplication(name = "Test", logLevel = "info")
@EnableCachingDefinedRegions(
    clientRegionShortcut = ClientRegionShortcut.PROXY,
    serverRegionShortcut = RegionShortcut.REPLICATE_HEAP_LRU)
@EnableClusterAware
@EnablePdx
public class CloudConfiguration {}

Я считаю, что зависимость Springboot gemfire Starter, которая у меня есть, достаточно хорош, чтобы автоматически считывать кредиты безопасности из VCAP_SERVICES без каких-либо ручных усилий. Но я вижу, что он не берет кредиты, не уверен, почему после того, как все зависимости ниже. Может кто-нибудь помочь? Спасибо

1 Ответ

1 голос
/ 22 апреля 2020

Хорошо ...

Сначала посмотрите мой ответ на ваше последнее ТАК сообщение о ваших зависимостях приложений. Правильное объявление зависимостей приложений было центральной темой в моем ответе.

Далее, ничего в Spring Data GemFire ​​ (SDG) само по себе не будет обрабатывать аутентификацию «автоматически» в управляемой среде, как PCF, при использовании P CC. Для этого вам абсолютно необходимо Spring Boot для Apache Geode или Pivotal GemFire ​​ (SBDG), а в вашем случае " .. для Pivotal GemFire ​​", и технически, зависимость org.springframework.geode:spring-gemfire-starter, которая является единственной зависимостью, которая вам нужна. Убедитесь, что вы выровняли версии, как я указывал в предыдущем посте .

Исходя из указанной выше конфигурации, вы явно " переопределили " конфигурацию безопасности клиента и автоконфигурация , предоставленная SBDG, поскольку вы явно объявили аннотацию @ClientCacheApplication для вашего CloudConfiguration класса.

Почему?

Ну, опять же, это GemFire / Geode, не Spring, а "Security" во всех его формах, включая GemFire ​​/ Geode (клиент / сервер, P2P, WAN и т. Д. c), должны быть правильно настроены и настроены перед кешем объект сконструирован и инициализирован.

Если объект кэша уже задан конфигурацией пользователя / приложения, тогда автоконфигурация SBDG для клиента GemFire ​​/ Geode Security будет не быть примененным. См. здесь (и, ну, здесь ).

Технически это связано с тем, что GemFire ​​/ Geode «Конфигурация безопасности» почти полностью настраивается через Свойства GemFire ​​/ Geode. Эти свойства должны быть объявлены / установлены перед созданием кэша, так как они передаются при создании кэша при запуске. Если они не предоставлены, конфигурация безопасности будет не применяться. Не имеет значения, если вы предоставите свойства Security позже, во время выполнения, либо с Spring , либо без него (например, просто используя непосредственно GemFire ​​/ Geode API), результат будет тем же!

GemFire ​​/ Geode имеет очень специфический c порядок для инициализации вещей: Auth, TLS / SSL, управление памятью, вот что, именно поэтому SBDG автоконфигурация была тщательно обработана чтобы убедиться, что соблюдается правильная последовательность инициализации.

Кроме того, независимо от того, используете ли вы аннотации конфигурации SDG (явно) или нет, скорее объявляя явные компоненты в контексте Spring с помощью JavaConfig, эффект тот же, так как конфигурация SDG аннотации неявно объявляют эти компоненты для вас, что приводит к «переопределению» автоматической конфигурации, предоставляемой Spring Boot и, в частности, SBDG.

Это работает так же, как GemFire ​​/ Геоде или нет. Если вы явно объявляете bean-компонент SQL DataSource, то вы говорите Boot переопределить предоставленный DataSource, если у вас есть встроенная база данных (H2 или H SQL) в вашем пути к классам приложения.

Идея такова: « соглашение по конфигурации » (просто объявив зависимости от пути к классу вашего приложения для автоматического включения функций), но также быстро убирается с пути, когда требования вашего приложения расходятся со значениями по умолчанию и вы должны явно объявить определение компонента определенного типа c, чтобы изменить конфигурацию в соответствии с требованиями вашего приложения, что обязательно отключит автоконфигурацию , предоставляемую Spring Boot , в противном случае вы бы имели неоднозначную и / или противоречивую конфигурацию (то есть что это). Spring Framework , как правило, не позволяет этого даже.

Снова удалите @ClientCacheApplication и @EnablePdx. Вам не нужны они с SBDG. Тем не менее, именно аннотация @ClientCacheApplication вызывает у вас проблемы здесь.

Таким образом, все это было подробно объяснено подробно в справочной документации:

  1. Глава 5 - Автоконфигурация
  2. Глава 6 - Декларативная конфигурация
  3. Глава 7 - Внешняя конфигурация ( с ссылкой на метаданные конфигурации в приложении ).

Особенно обратите внимание на Переопределение автоконфигурации в Глава 4 .

Надеюсь, это поможет!

...