AllowMove: false does not seem to work

Hi,

I have two instances of Orthanc 1.5.4 running, instance A and instance B. I want instance A not to be able to access the images in instance B, but I want instance B to be able to access the images in instance A. Some goes for C-MOVEs.

So in Instance B I configured:

"DicomModalities" : { "A" : { "AET": "INSTANCE-A", "Port": 123, "Host": "10.0.0.1", "AllowEcho": true, "AllowFind": false, "AllowMove": false, "AllowStore": false } }

Now, as expected, I will get an Error if I C-FIND instance B from instance A. However, sending images from instance A to instance B works.
What am I doing wrong? Isn’t “AllowMove” supposed to reject this behavior?

Thanks.

Best Regards,
Georg

Hello,

Let’s consider this Orthanc configuration file:

{
“DicomModalities” : {
“untrusted” : {
“AET” : “A”,
“Port” : 104,
“Host” : “127.0.0.1”,
“AllowMove” : false
},
“trusted” : {
“AET” : “B”,
“Port” : 104,
“Host” : “127.0.0.1”,
“AllowMove” : true
},
“target” : [ “STORESCP”, “localhost”, 2000 ]
}
}

Let’s upload the following DICOM instance from the integration tests of Orthanc:
https://bitbucket.org/sjodogne/orthanc-tests/raw/default/Database/DummyCT.dcm

Let’s initiate two C-MOVE SCU connections to Orthanc SCP (with the study instance UID from “DummyCT.dcm”), the first one from untrusted AET “A”, and the second one from trusted AET “B”:

$ movescu -aet A -aec ORTHANC -aem STORESCP localhost 4242 -k QueryRetrieveLevel=STUDY -k StudyInstanceUID=1.2.840.113619.2.176.2025.1499492.7391.1171285944.390
E: Move Request Failed: 0006:0317 Peer aborted Association (or never connected)

$ movescu -aet B -aec ORTHANC -aem STORESCP localhost 4242 -k QueryRetrieveLevel=STUDY -k StudyInstanceUID=1.2.840.113619.2.176.2025.1499492.7391.1171285944.390

I: Requesting Association

I: Association Accepted (Max Send PDV: 16372)
I: Sending Move Request (MsgID 1)
I: Request Identifiers:
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [STUDY] # 6, 1 QueryRetrieveLevel
I: (0020,000d) UI [1.2.840.113619.2.176.2025.1499492.7391.1171285944.390] # 54, 1 StudyInstanceUID
I:
I: Received Final Move Response (Success)
I: Releasing Association

As can be seen, the first call fails (as expected as C-MOVE is forbidden for this modality), whereas the second call succeeds.

So, the behavior of Orthanc seems correct.

Regards,
Sébastien-

Thanks for clarifying Sébastien.
I can verify it works as expected using movescu. However, I tried moving the study using the “Send to remote modality” button in the web interface initially, for which it will work. Is it possible the “Send to remote modality” button is treated differently in any way to performing the C-MOVE using movescu?

Thanks,
Georg

I see that the Orthanc web interface performs C-STOREs instead of MOVEs. I turned off “AllowStore” for this modality too, though.

Performing

storescu -aet A -aec B localhost 4242 file.dcm

works though, even though I configured B (an Orthanc server), to reject stores from this guy. Again here is the config of B:

“DicomModalities” : {

“A” : {

“AET”: “A”,
“Port”: 4242,
“Host”: “10.0.0.2”,
“AllowEcho”: true,
“AllowFind”: false,
“AllowMove”: false,
“AllowStore”: false
}
}

These options “AllowXXX” in the “DicomModalities” section drive the behavior of Orthanc when it acts as a DICOM SCP (server).

However, in your context, you are willing to restrict the behavior of Orthanc when it acts as a DICOM SCU (client) after an action triggered by the REST API. This is not the purpose of the “AllowXXX” options in “DicomModalities”.

Check out instead:
http://book.orthanc-server.com/users/lua.html#filtering-incoming-rest-requests

=> In your example, this callback can “return false” if the URI matches “/modalities/A/store”.

Thanks for being so patient with me Sébastien.
I might be wrong, but when I do

storescu -aet A -aec B localhost 4242 file.dcm

I act as a DICOM client (with AET A), wanting to give file.dcm to AET B, which acts as a Store SCP in this case. On AET B I configure that I do not want STOREs from SCU AET A. So shouldn’t “AllowStore” be applicable in this case?

Thanks,
Georg

In your example, what is the AET of Orthanc? “A” or “B”?

Well, both AETs are Orthanc in my test environment, but AET B is the one acting as the Store SCP, who should reject AET A’s Store request.

"DicomModalities" : { "A" : { "AET": "A", "Port": 123, "Host": "10.0.0.1", "AllowEcho": true, "AllowFind": false, "AllowMove": false, "AllowStore": false } }

Hello,

You must set the two following options to “false” in the Orthanc configuration for your configuration to have an effect:

“DicomAlwaysAllowEcho” : false,
“DicomAlwaysAllowStore” : false

Sébastien-

Hi Sébastien,

ah, thank you very much. I did not anticipate these options overwriting my explicit configuration in DicomModalities. Do you think it would be a good idea to perhaps extend the documentation in the configuration file regarding the per-modality configuration?
Perhaps

As the default behavior of Orthanc is to always accept DIMSE-C commands, the 
"AllowEcho" and "AllowStore" options only have an effect if the global
overrides "DicomAlwaysAllowEcho" and "DicomAlwaysAllowStore" are set to false.

Maybe that will prevent people making the same mistake in the future.

Thanks!

Georg

Indeed, this is now documented by the following changeset:
https://bitbucket.org/sjodogne/orthanc/commits/5b7f56cf4a38408d625ed61c9248db3abd97e4a7

Sébastien-