26.0.x: DPY-6006 with TCPS + SCAN listener: server cert is checked against the redirect host, not the DSN host (regression of #415)
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
調査の方向性
Start in src/oracledb/impl/thin/connection.pyx at the redirect branch around line 284, then trace how tcp_connect_sub_op.address reaches TLS certificate validation in src/oracledb/impl/thin/crypto.pyx. Reproduce with the reported TCPS/SCAN setup and compare the original DSN host with the redirect host used for certificate checking. Done means the connection validates against the DSN host while Connection.host and port retain the connected node; verify the reported connection and pool cases.
索引モデルが issue の本文から書いたものです。
説明
- What versions are you using?
connection.version: 19.32.0.0.0
oracledb.clientversion: 26.0.1
platform.platform: Linux-6.8.0-1067-azure-x86_64-with-glibc2.34
platform.python_version: 3.11.13
- Is it an error or a hang or a crash?
error
- What error(s) or behavior you are seeing?
Connecting over TCPS through a RAC SCAN listener fails during TLS negotiation. The failure happens after the SCAN listener redirects the client to a node listener:
File "src/oracledb/impl/thin/connection.pyx", line 192, in oracledb.thin_impl.ThinConnImpl._connect
File "src/oracledb/impl/thin/connection.pyx", line 292, in _connect_phase_one
File "src/oracledb/impl/base/connection.pyx", line 443, in oracledb.base_impl.BaseConnImpl.process_sync_operation
File "src/oracledb/impl/thin/connection.pyx", line 657, in oracledb.thin_impl.ThinConnImpl._process_sync_operation_sub_op
File "src/oracledb/impl/thin/connection.pyx", line 1304, in oracledb.thin_impl.TcpConnectSubOp.process
File "src/oracledb/impl/thin/protocol.pyx", line 175, in oracledb.thin_impl.Protocol._connect_tcp
File "src/oracledb/impl/thin/transport.pyx", line 270, in oracledb.thin_impl.Transport.negotiate_tls
File "src/oracledb/impl/thin/crypto.pyx", line 114, in oracledb.thin_impl.check_server_dn
...
oracledb.exceptions.OperationalError: DPY-6005: cannot connect to database (CONNECTION_ID=...).
DPY-6006: The name on the server certificate does not match the expected value: "10.x.x.x"
The "expected value" is the IP address from the listener's redirect, not the host in the DSN. The server certificate is issued for the SCAN hostname (the DSN host), so it can never match that IP. With the same DSN and certificate, 4.0.2 connects fine.
This looks like a regression of #415, which was fixed in 3.0.0. In 4.0.2, when a redirect happens, Protocol._connect_phase_one reconnects to the redirect host/port but still passes the original address to _connect_tcp. As a result, check_server_dn validates against the DSN host.
In 26.0.x, the connect logic moved to ThinConnImpl. The redirect branch (src/oracledb/impl/thin/connection.pyx, around line 284 at v26.0.1) now overwrites the host on the address that is later passed to negotiate_tls:
temp_address = temp_params._get_addresses()[0]
db_address = db_address.copy()
db_address.host = temp_address.host # <- redirect host replaces DSN host
db_address.port = temp_address.port
tcp_connect_sub_op.host = temp_address.host
tcp_connect_sub_op.port = temp_address.port
tcp_connect_sub_op.address = db_address # <- used by check_server_dn(..., address.host)
I'm guessing the copy is there so that Connection.host/port (new in 26.0.0) report the node actually connected to. If that's right, a fix could keep that behavior and still pass the original DSN host to check_server_dn.
- Does your application call init_oracle_client()?
No. This is Thin mode.
- Include a runnable Python script that shows the problem.
No schema is needed. To reproduce, you need a RAC database whose SCAN listener uses TCPS and redirects to the node listeners by IP address. The server certificate's CN/SAN must contain the SCAN hostname and not the node IPs. ssl_server_dn_match is left at its default (True).
import oracledb
conn = oracledb.connect(
user="...",
password="...",
dsn="my-cluster-scan.example.com:2484/my_service.example.com",
protocol="tcps",
)
print(conn.version) # works on 4.0.2; DPY-6006 on 26.0.0 / 26.0.1
The same failure happens with oracledb.create_pool(...) and pool.acquire().
- 主要言語
- Python
- スター
- 454
- フォーク
- 119
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
oracle/python-oracledb のほかの issue
-
asyncio: DPY-4011 on connect_async() when the listener closes the original socket after a redirect対応中かも @AlexGracas が 6 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
oracle/python-oracledb#616 ·
-
Fetch character columns as raw bytes in the database character set into data frames (Thick mode)オープンenhancement
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
oracle/python-oracledb#614 · コメント 1 件 ·
-
Client Library or Database
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
oracle/python-oracledb#613 · コメント 3 件 ·
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 40/100
oracle/python-oracledb#612 ·
-
enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
oracle/python-oracledb#611 · コメント 4 件 ·
oracle/python-oracledb の issue をすべて見る
似ている issue
-
effort: low prio: low ready
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
digitalfabrik/integreat-cms#4616 ·
メンテナーはふだん 5 日以内に返信
-
bug difficulty:2 good first issue help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
MakazhanAlpamys/Soup#1865 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
FinanceFlash/unvibecode#233 ·
メンテナーはふだん 1 日以内に返信
-
area: agents area: docs good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
openapi/gknowledge#23 ·
-
useless-suppression reported for deprecated-* messages that should be exempt対応中かも @adityasinha-ghub が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
pylint-dev/pylint#11656 ·
メンテナーはふだん 1 日以内に返信