We’ve implemented the Authorization Plugin with Osimis web viewer, but some requests are returning 403, even though the web service is returning granted.
In fact, when loading the web viewer, two identical concurrent resource calls occur for a study and one 403s and the other 200s. And sometimes both 200s and sometime both 403s?
Has anyone else experienced this? Is this an incompatability with the Osimes Web Viewer and the Authorization plugin?
Hi Deon,
I’m quite puzzled by the inconsistencies. BTW, there’s an issue now with the webviewer since, when performing internal calls to the Orthanc REST API, it won’t include the HTTP headers from your original requests. This means that most of these calls will be rejected by the authorization plugin since they lack of authentication header.
There’s a work in progress to fix it (but it’s quite stalled right now): https://bitbucket.org/osimis/osimis-webviewer-plugin/branch/am-http-headers
Br
Hi Alain
Thanks for this.
We’re using the Auth plugin through docker - is there a way seeing the verbose logs of what calls the Auth plugin are making? Including headers etc.
I’m also really puzzled by this. I wonder if the inconsistent 403s might be because some of the REST API calls are not being done internally, and are succeeding and being cached as granted, and on refresh the internal calls are reading the cached granted result, and then returning 200?
In fact, I notice now, that even through there is a call to http://0.0.0.0/orthanc/renderer/studies/3abaec0a-ebfaaa87-f830d52b-d62df074-6a692c12, a studies resource when the viewer loads,
it only does the patient auth, but never the the studies call.
This turned out to be the CURL call of the Authorization Plugin to our web service timing out on my local dev. Setting the HTTP_TIMEOUT env variable has not affect on this particular CURL call.
This post seems related:
https://groups.google.com/d/msg/orthanc-users/GtEaM_HOHJ0/1pGNjsLYBgAJ