comparison NEWS @ 59:a5f2976fe8a0

fix Authorization header conflicting with WebServiceUsername
author Alain Mazy <am@osimis.io>
date Thu, 10 Nov 2022 10:25:01 +0100
parents ad279c70c22d
children a2ed57d8a2f0
comparison
equal deleted inserted replaced
58:ad279c70c22d 59:a5f2976fe8a0
5 "UncheckedLevels" remains for backward compatibility. 5 "UncheckedLevels" remains for backward compatibility.
6 Allowed values: "patients", "studies", "series", "instances" 6 Allowed values: "patients", "studies", "series", "instances"
7 * new configuration option "StandardConfigurations" to replace multiple configurations. 7 * new configuration option "StandardConfigurations" to replace multiple configurations.
8 Allowed values: "osimis-web-viewer", "stone-webviewer" 8 Allowed values: "osimis-web-viewer", "stone-webviewer"
9 * added support for QIDO-RS query arguments (e.g: /dicom-web/studies?0020000D=1.2.3&...) 9 * added support for QIDO-RS query arguments (e.g: /dicom-web/studies?0020000D=1.2.3&...)
10 10 * possible BREAKING_CHANGE: if "TokenHttpHeaders" is set to "Authorization" and if
11 "WebServiceUsername" is defined, the "Authorization" header of the HTTP request
12 sent to the auth-service will contain the basic auth info from WebServiceUsername and
13 WebServicePassword. You should get the "Authorization" value from the token-value field
14 of the payload sent to the auth-service.
11 15
12 2022-09-26 - v 0.3.0 16 2022-09-26 - v 0.3.0
13 ==================== 17 ====================
14 18
15 * Added 3 new configurations: WebServiceUsername, WebServicePassword, WebServiceIdentifier. 19 * Added 3 new configurations: WebServiceUsername, WebServicePassword, WebServiceIdentifier.