【问题标题】:Hibernate OGM Upgrade causing Mongo authentication issue休眠 OGM 升级导致 Mongo 身份验证问题
【发布时间】:2017-08-10 15:34:14
【问题描述】:

我正在尝试使用以下内容升级我的应用程序:

  1. Mongo db 2.6.5 到 3.4.2
  2. 将 OGM 从 4.2.0.Final 休眠到 5.1.0.Final

我在使用 OGM 5.1 时遇到了身份验证失败,但在使用 OGM 4.2 时它可以正常工作

异常堆栈 -

com.mongodb.MongoSecurityException: 异常验证 MongoCredential{mechanism=null, userName='prodhub', source='admin', password=,mechanismProperties={}} 在 com.mongodb.connection.SaslAuthenticator.wrapInMongoSecurityException(SaslAuthenticator.java:157) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.SaslAuthenticator.access$200(SaslAuthenticator.java:37) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.SaslAuthenticator$1.run(SaslAuthenticator.java:66) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.SaslAuthenticator$1.run(SaslAuthenticator.java:44) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.SaslAuthenticator.doAsSubject(SaslAuthenticator.java:162) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.SaslAuthenticator.authenticate(SaslAuthenticator.java:44) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.DefaultAuthenticator.authenticate(DefaultAuthenticator.java:32) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.InternalStreamConnectionInitializer.authenticateAll(InternalStreamConnectionInitializer.java:109) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.InternalStreamConnectionInitializer.initialize(InternalStreamConnectionInitializer.java:46) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.InternalStreamConnection.open(InternalStreamConnection.java:116) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.DefaultServerMonitor$ServerMonitorRunnable.run(DefaultServerMonitor.java:113) ~[mongo-java-driver-3.4.2.jar:na] 在 java.lang.Thread.run(Thread.java:745) [na:1.8.0_72] 原因:com.mongodb.MongoCommandException:命令失败,错误 18:“身份验证失败。”在服务器 localhost:27017 上。完整的响应是 { "ok" : 0.0, "errmsg" : "Authentication failed.", "code" : 18, "codeName" : "AuthenticationFailed" } 在 com.mongodb.connection.CommandHelper.createCommandFailureException(CommandHelper.java:170) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.CommandHelper.receiveCommandResult(CommandHelper.java:123) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.CommandHelper.executeCommand(CommandHelper.java:32) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.SaslAuthenticator.sendSaslStart(SaslAuthenticator.java:117) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.SaslAuthenticator.access$000(SaslAuthenticator.java:37) ~[mongo-java-driver-3.4.2.jar:na] 在 com.mongodb.connection.SaslAuthenticator$1.run(SaslAuthenticator.java:50) ~[mongo-java-driver-3.4.2.jar:na] ...省略了9个常用框架

我遇到了这个 jira - https://hibernate.atlassian.net/browse/OGM-791 ,这表明我可能需要进行 mongo 身份验证方案迁移。

我的持久化xml是这样的--

<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
  <persistence-unit name="productHub">
    <provider>org.hibernate.ogm.jpa.HibernateOgmPersistence</provider>
    <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>

        <properties>

            <property name="hibernate.ogm.datastore.provider" value="mongodb" /> 

            <property name="hibernate.ogm.datastore.database" value="test" /> 
            <!-- property name="hibernate.ogm.datastore.host" value="localhost" / --> 
            <!-- property name="hibernate.ogm.datastore.port" value="27017" / -->
            <property name="hibernate.ogm.datastore.username" value="prodhub" /> 
            <property name="hibernate.ogm.datastore.password" value="xxxxxxxxx" />
            <property name="hibernate.ogm.mongodb.connection_timeout" value="6000" />

            <!-- property name="hibernate.ogm.mongodb.authentication_mechanism" value="MONGODB_CR" / -->

            <property name="hibernate.cache.use_second_level_cache" value="false" />

            <!--
            <property name="hibernate.search.default.directory_provider" value="filesystem" />
            <property name="hibernate.search.default.indexBase" value="D:\\Projects\\prodhub\\lucene" />


            <property name="jboss.as.jpa.managed" value="false" />
            -->

        </properties>

  </persistence-unit>
</persistence>

mongo 日志显示 -

2017-03-19T01:37:37.352+0530 I NETWORK [thread1] 接受来自 127.0.0.1:62379 #640 的连接(现在打开 2 个连接) 2017-03-19T01:37:37.353+0530 I NETWORK [conn640] 从 127.0.0.1:62379 conn640 收到客户端元数据:{驱动程序:{名称:“mongo-java-driver”,版本:“3.4.2”},操作系统:{类型:“Windows”,名称:“Windows 7”,架构:“amd64”,版本:“6.1”},平台:“Java/Oracle Corporation/1.8.0_72-b15”} 2017-03-19T01:37:37.355+0530 I ACCESS [conn640] SCRAM-SHA-1 身份验证在来自客户端 127.0.0.1:62379 的管理员上的 prodhub 失败; UserNotFound:找不到用户 prodhub@admin 2017-03-19T01:37:37.356+0530 I - [conn640] 结束连接 127.0.0.1:62379(现在打开 2 个连接)

如果我将身份验证机制更改为 MONGODB_CR,我会收到以下日志消息 -

[conn667] 从 127.0.0.1:64331 conn667: { driver: { name: "mongo-java-driver", version: "3.4.2" }, os: { type: "Windows", name :“Windows 7”,架构:“amd64”,版本:“6.1”},平台:“Java/Oracle Corporation/1.8.0_72-b15”} 2017-03-19T15:10:33.346+0530 我访问 [conn667] 验证 db: admin { 验证: 1, 用户: "prodhub", nonce: "xxx", key: "xxx" } 2017-03-19T15:10:33.347+0530 I ACCESS [conn667] 无法使用 MONGODB-CR 机制验证 prodhub@admin:AuthenticationFailed:UserNotFound:找不到用户 prodhub@admin 2017-03-19T15:10:33.349+0530 I - [conn667] 结束连接 127.0.0.1:64331(现在打开 2 个连接)

从错误堆栈和日志消息中,是否确认我需要通过这里提到的身份验证迁移过程 - https://docs.mongodb.com/manual/release-notes/3.0-scram/

或者我应该在升级之前查找更多诊断信息吗?

【问题讨论】:

  • 即使升级也没有用! > db.adminCommand({authSchemaUpgrade: 1}); { "done" : true, "ok" : 1 } .. 仍然出现同样的错误
  • 我不知道 MongoDB 是否返回安全异常的一般错误,但看起来您有 UserNotFound 错误。您确定该用户存在于您尝试访问的数据库中吗?
  • 没错。用户不在身份验证数据库中,导致错误。

标签: mongodb hibernate-ogm


【解决方案1】:

我找到了解决方案。从这个线程中获取线索 - MongoDb authentication using Hibernate OGM ,我在 "admin" db 中创建了用户,这似乎是 mongo 3.x 中的默认身份验证数据库。早些时候,用户驻留在我的“测试”数据库中。

我想,将属性“hibernate.ogm.mongodb.authentication_database”设置为“test”可能也有效,但我还没有尝试过。

【讨论】:

  • 这是一个有效的解决方案,尽管您提到的属性是无法更新数据库的人的替代方案
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-05-30
  • 1970-01-01
  • 2017-08-03
  • 1970-01-01
  • 2019-04-03
  • 2021-03-02
相关资源
最近更新 更多