View in #ohif on Slack
@Cl_D: hi @Bill_Wallace - was setting up staticDICOM on S3 as per https://github.com/RadicalImaging/Static-DICOMWeb/blob/f5ae5e9567b42b3e402c7e4298f76eece81c4199/packages/s3-deploy/README.md - but had a question about deploying OHIF - where is deploydicomweb?
@Bill_Wallace: It is in the static dicomweb package @radicalimaging/static-wado-deploy
npm install -g @radicalimaging/static-wado-deploy should work
@Cl_D: Thanks @Bill_Wallace
hi again @Bill_Wallace to deploy OHIF, the instructions indicate using the dicomweb datasource definition from e2e.js which is this - {
friendlyName: ‘StaticWado default data’,
namespace: ‘@ohif/extension-default.dataSourcesModule.dicomweb’,
sourceName: ‘dicomweb’,
configuration: {
name: ‘DCM4CHEE’,
wadoUriRoot: ‘/dicomweb’,
qidoRoot: ‘/dicomweb’,
wadoRoot: ‘/dicomweb’,
qidoSupportsIncludeField: false,
supportsReject: false,
imageRendering: ‘wadors’,
thumbnailRendering: ‘wadors’,
enableStudyLazyLoad: true,
supportsFuzzyMatching: false,
supportsWildcard: true,
staticWado: true,
bulkDataURI: {
enabled: true,
relativeResolution: ‘studies’,
},
},
},
but it looks like there’s an ohif datasource definition specifically for S3 - {
namespace: ‘@ohif/extension-default.dataSourcesModule.dicomweb’,
sourceName: ‘ohif’,
configuration: {
friendlyName: ‘AWS S3 Static wado server’,
name: ‘aws’,
wadoUriRoot: ‘https://d14fa38qiwhyfd.cloudfront.net/dicomweb’,
qidoRoot: ‘https://d14fa38qiwhyfd.cloudfront.net/dicomweb’,
wadoRoot: ‘https://d14fa38qiwhyfd.cloudfront.net/dicomweb’,
qidoSupportsIncludeField: false,
imageRendering: ‘wadors’,
thumbnailRendering: ‘wadors’,
enableStudyLazyLoad: true,
supportsFuzzyMatching: false,
supportsWildcard: true,
staticWado: true,
singlepart: ‘video,pdf’,
bulkDataURI: {
enabled: true,
relativeResolution: ‘studies’,
transform: url => url.replace(‘/pixeldata.mp4’, ‘/rendered’),
},
},
},
wondering which one i should use?
@Bill_Wallace: Either one is fine - they are both static dicomweb server based instances. The first one gets served up via the yarn test:e2e:serve command, while the second one is run externally as dicomwebserver
@Cl_D: thanks again @Bill_Wallace - curious about the roots - are relative paths ok or are the full cloudfront addresses required
@Bill_Wallace: Relative paths should work as long as they are relative to either the root url (as in the first example), or relative to the root URL specified in the html and start with a ./ or just the relative sub-path.
@Cl_D: Hi @Bill_Wallace and @Alireza_Sedghi - uploaded a study using deploydicomweb. at the end of the upload, it did note “No index defined in group”. unfortunately still having the same 403 forbidden error. when i try to open the cloudfront site with /dicomweb/studies i still see Access Denied even after turning off “block all public access” in the dicomweb bucket permissions.
opening the cloudfront site itself immediately opens OHIF viewer but with error Data Source Connection Error
Error: request failed
Please ensure the following data source is configured correctly or is running:
AWS S3 Static wado server
and using this datasource configuration -
{
namespace: ‘@ohif/extension-default.dataSourcesModule.dicomweb’,
sourceName: ‘dicomweb’,
configuration: {
friendlyName: ‘AWS S3 Static wado server’,
name: ‘aws’,
wadoUriRoot: ‘/dicomweb’,
qidoRoot: ‘/dicomweb’,
wadoRoot: ‘/dicomweb’,
qidoSupportsIncludeField: false,
imageRendering: ‘wadors’,
thumbnailRendering: ‘wadors’,
enableStudyLazyLoad: true,
supportsFuzzyMatching: false,
supportsWildcard: true,
staticWado: true,
singlepart: ‘thumbnail’,
acceptHeader: [‘multipart/related; type=application/octet-stream; transfer-syntax=*’],
bulkDataURI: {
enabled: true,
relativeResolution: ‘studies’,
transform: url => url.replace(‘/pixeldata.mp4’, ‘/rendered’),
},
},
},
@Bill_Wallace: Try https://hostname/dicomweb/studies
That should get you a studies JSON response. Until that is done, the rest won’t work
@Cl_D: thanks @Bill_Wallace https://hostname/dicomweb/studies still returns Access Denied even after turning off block public access and createInvalidation
@Bill_Wallace: And is there a studies file in the s3 bucket under /dicomweb/studies It should have a header of type json and gzip compressed
@Cl_D: yes, there is a studies file in the s3 bucket under /dicomweb/studies
grabbing a cloudfront log file now for further analysis
looks like it’s a KMS issue - still working on it
i was using AWS-managed KMS key which didn’t have the correct permissions to decrypt and since AWS-managed keys can’t be modified, ended up using a customer-managed key and re-encrypting the files. started working immediately after that. thanks again @Bill_Wallace and @Alireza_Sedghi
also, my dicomweb origin is using OAC, not OAI
and my bucket policy is - {
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“Service”: “cloudfront.amazonaws.com”
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::xxxxxxxxxxxx/",
“Condition”: {
“StringEquals”: {
“AWS:SourceArn”: “arn:aws:cloudfront:
xxxxxxxxxxx:distribution/xxxxxxxxxxxx”
}
}
}
]
}
and the additional KMS policy needed is - {
“Sid”: “Allow CloudFront to Decrypt Objects”,
“Effect”: “Allow”,
“Principal”: {
“Service”: “cloudfront.amazonaws.com”
},
“Action”: [
“kms:Decrypt”,
“kms:DescribeKey”
],
“Resource”: "”,
“Condition”: {
“StringEquals”: {
“AWS:SourceArn”: “arn:aws:cloudfront:xxxxxxxxxxx:distribution/xxxxxxxxxxxx”
}
}
}
@Bill_Wallace: Could you submit a PR to update the insructions with what it was that you needed to include/change to make things work?
@Cl_D: yes 