Ошибка «SSL не имеет действительного хранилища ключей» при попытке подключения к Datomic Cloud - PullRequest
Новая
       9

Ошибка «SSL не имеет действительного хранилища ключей» при попытке подключения к Datomic Cloud

0 голосов
/ 14 мая 2018

Я пытаюсь переключиться на проект, чтобы использовать новое двухатомное облако . Я создал стек с помощью панели инструментов AWS и даже смог подключиться к нему в простой реплике clojure с необходимыми зависимостями. Но мне было трудно установить соединение с работой из моего проекта.

Сначала я столкнулся с кучей конфликтов зависимостей - действительно, это все еще может быть коренной проблемой здесь - поэтому я добавил некоторые исключения к своему включению двухатомного проекта в мой project.clj: 

 [com.datomic/client-cloud "0.8.50"
  :exclusions [org.eclipse.jetty/jetty-io
               org.eclipse.jetty/jetty-util
               commons-logging
               commons-codec]]

Затем, когда я пытался подключиться в lein repl с 

(require '[datomic.client.api :as d])
(def cfg {:server-type :cloud
          :region "us-east-2"
          :system "<sysname>"
          :query-group "<sysname>"
          :endpoint "http://entry.<sysname>.us-east-2.datomic.net:8182/"
          :proxy-port 8182})
(def client (d/client cfg))

Я закончил со следующей ошибкой:

2018-05-13 20: 36: 01.593: ПРЕДУПРЕЖДЕНИЕ: oejuc.AbstractLifeCycle: nREPL-worker-1: FAILED SslContextFactory @ 56f447c4 (null, null): java.lang.IllegalStateException: SSL не имеет действительного хранилища ключей > java.lang.IllegalStateException: у SSL нет действительного хранилища ключей`

Этот ставит меня в тупик. Вот пастбин с полной трассировкой стека: https://pastebin.com/cRGyVmnT. Я предполагаю, что может быть проблема с вызовом неверной версии Jetty, но я не уверен, какие дальнейшие шаги попробовать. Мысли?

Ответы [ 3 ]

0 голосов
/ 04 июня 2018

Если вы укажете более свежие версии зависимостей для jetty-server и jetty-client, это должно наконец сработать.Вот что сработало для меня: 

:dependencies [[org.clojure/clojure "1.9.0"]
             [ring/ring-core "1.7.0-RC1"]
             [ring/ring-jetty-adapter "1.7.0-RC1"]
             [org.eclipse.jetty/jetty-server "9.4.9.v20180320"] 
             [org.eclipse.jetty/jetty-client "9.4.9.v20180320"] 
             [com.datomic/client-cloud "0.8.52"]]

Для полной демонстрации см. https://github.com/ezmiller/datomic-ring-dep-conflict/pull/1/files

0 голосов
/ 26 сентября 2018

Обходным решением для меня было заменить реализацию ssl-context-factory на alter-var-root +, чтобы вместо этого использовать следующие зависимости: 

org.eclipse.jetty/jetty-http         {:mvn/version "9.2.24.v20180105"}
org.eclipse.jetty/jetty-io           {:mvn/version "9.2.24.v20180105"}
org.eclipse.jetty/jetty-util         {:mvn/version "9.2.24.v20180105"}
org.eclipse.jetty/jetty-client       {:mvn/version "9.2.24.v20180105"}

Недостатком является то, что теперь все доверяет, но, возможно, что-то оптимальноеКонфигурация может быть найдена. 

   (defn ssl-context-factory-replacement
      ^SslContextFactory [{:keys [trust-all classpath-trust-store trust-store-password trust-store validate-hostnames]}]
      (SslContextFactory. true))`enter code here`

    (alter-var-root
     #'cognitect.http-client/ssl-context-factory
     (constantly ssl-context-factory-replacement))
0 голосов
/ 14 мая 2018

Я нашел решение для этого, основываясь на предложении @Aleph Aleph в комментариях к вопросу выше. Что я сделал, так это добавил исключения в пакет с зависимостями, конфликтующими с datomic/cloud-client.

Я посмотрел на эти конфликты, присмотревшись к lein deps :tree | grep jetty. В частности, он показал следующее: 

[ring "1.6.3" :exclusions [org.eclipse.jetty/jetty-client org.eclipse.jetty/jetty-http org.eclipse.jetty/jetty-util]] -> [ring/ring-jetty-adapter "1.6.3"] -> [org.eclipse.jetty/jetty-server "9.2.21.v20170120"] -> [org.eclipse.jetty/jetty-
io "9.2.21.v20170120"]
 overrides
[com.datomic/client-cloud "0.8.50"] -> [com.datomic/client "0.8.40"] -> [com.datomic/client-impl-shared "0.8.34"] -> [com.cognitect/http-client "0.1.83"] -> [org.eclipse.jetty/jetty-client "9.3.7.v20160115"] -> [org.eclipse.jetty/jetty-io
 "9.3.7.v20160115"]
 and
[com.datomic/client-cloud "0.8.50"] -> [com.datomic/client-impl-shared "0.8.34"] -> [com.cognitect/http-client "0.1.83"] -> [org.eclipse.jetty/jetty-client "9.3.7.v20160115"] -> [org.eclipse.jetty/jetty-io "9.3.7.v20160115"]
 and
[com.datomic/client-cloud "0.8.50"] -> [com.datomic/client "0.8.40"] -> [com.cognitect/http-client "0.1.83"] -> [org.eclipse.jetty/jetty-client "9.3.7.v20160115"] -> [org.eclipse.jetty/jetty-io "9.3.7.v20160115"]

Как видно, зависимость, исходящая от ring, называемая ring/ring-jetty-adapter, содержала несколько версий пакетов, переопределяющих версии в двухатомном облаке. Поэтому я добавил следующее, исправляя проблему: 

[ring "1.6.3"
 :exclusions [ring/ring-jetty-adapter]]
...