Bug #7954
SyncFailedTask:submitSynchronizationFailed does not provide cert when connecting to MN
0%
Description
From Jing: i looked at the code, the session always be null in The SyncFailedTask. Metacat does the same way since the session is set up on the tomcat level.
Resulting error generated by GMN and logged by cn-process-daemon:
(SyncFailedTask:submitSynchronizationFailed:128) Task-urn:node:R2R-63c5788a81aa957f71d47c8c95a0c9e55cf391ba <?xml
version="1.0" encoding="UTF-8"?>
Access allowed only for trusted subjects. active_subjects="public (primary)",
trusted_subjects="CN=localClient, CN=urn:node:CN,DC=dataone,DC=org, CN=urn:node:CNORC1,DC=dataone,DC=org,
CN=urn:node:CNUCSB1,DC=dataone,DC=org, CN=urn:node:CNUNM1,DC=dataone,DC=org,
CN=urn:node:R2R,DC=dataone,DC=org"
base.py(185)
decorators.py(185)
restrict_to_verb.py(36)
auth.py(238)
auth.py(277)
History
#1 Updated by Dave Vieglais about 7 years ago
- Project changed from CN REST to Infrastructure
- Milestone set to None
- Target version set to CCI-2.3.3
- Category changed from d1_cn_process_daemon to d1_synchronization
#2 Updated by Jing Tao about 7 years ago
I checked the Metacat code and Metacat only allows cn certificate to call this method. If the cn doesn't set the certificate, Metacat should reject the call.
However, in the dev.nceas.ucsb.edu, which is the cn-stage-2 environment, i can see the records on the access_log file:
221996 | 129.237.201.86 | Apache-HttpClient/4.3.3 (java 1.5) | CN=urn:node:cnStageUNM2,DC=dataone,DC=org | autogen.2016041415161498760.1 | synchronization_failed | 2016-08-03 09:30:47.37
221997 | 129.237.201.86 | Apache-HttpClient/4.3.3 (java 1.5) | CN=urn:node:cnStageUNM2,DC=dataone,DC=org | autogen.2016041415493137144.1 | synchronization_failed | 2016-08-03 09:30:48.023
221998 | 129.237.201.86 | Apache-HttpClient/4.3.3 (java 1.5) | CN=urn:node:cnStageUNM2,DC=dataone,DC=org | autogen.2016041415022580049.1 | synchronization_failed | 2016-08-03 09:30:48.112
So it did log the synchronization failures. So I believe CN did set the certificate.
The KNB did log the synchronization failures as well. But they happened in 2013.
#3 Updated by Jing Tao about 7 years ago
- Related to Task #8060: CN failed to call MN.synchronizationFailed method for the arctic data center and knb mn added
#4 Updated by Jing Tao about 7 years ago
- Related to deleted (Task #8060: CN failed to call MN.synchronizationFailed method for the arctic data center and knb mn )
#5 Updated by Jing Tao about 7 years ago
- Assignee changed from Jing Tao to Roger Dahl
Hi Roger:
Metacat can sucessfully accept the call of synchronizationFailed method from CNs even though it checks the certificates of the caller and only allows cns call it. That means cn does pass its certificate to mns during the calling. I am wondering if there is some configuration issue on the GMN node.
So I assigned this ticket to you.
Thanks,
Jing
#6 Updated by Jing Tao about 7 years ago
- Target version changed from CCI-2.3.3 to CCI-2.4.0
