Hello everyone, hope you’re doing well.,
I am using Orthanc with authentication enabled and accessing it from a Django backend using pyorthanc.
From Django, I successfully authenticate and fetch study/series metadata like this:
server = Orthanc(“https://pacs.example.com”, username=“admin”, password=“****”)
study = server.get_studies_id(study_id)
This works correctly.
However, when I send the instance preview URL to the frontend:
https://pacs.example.com/instances/{instanceId}/preview
and load it in the browser (e.g. using an tag), Orthanc always prompts for username/password.
I also tried embedding the credentials directly in the URL, like:
https://username:password@pacs.example.com/instances/{instanceId}/preview
but this results in a 401 Unauthorized response and does not work in the browser.
What is the recommended way to serve instance preview images in a web application without triggering the Orthanc login prompt?
Hello,
This is expected, as HTTP basic authentication is automatically enabled as soon as RemoteAccessAllowed is set to true. As a highly insecure solution, you could set AuthenticationEnabled to false. Do not do this in production, as anybody will be allowed to access the full REST API.
The recommended option is to put a reverse proxy (nginx or Apache, yet your Django application) in front of Orthanc and let it handle authentication and authorization. In this case, the Orthanc server can run in a “service mode”, using credentials that are only known to your reverse proxy.
Kind Regards,
Sébastien-
Thank you for the suggestion, Jodogne.
I already have Nginx running in front of Orthanc as a reverse proxy. When I hard-code the Orthanc credentials in the Nginx configuration, everything works as expected. However, when I remove the hard-coded credentials and try to handle authentication in a more dynamic way, I start encountering the issue I described earlier, particularly with serving preview images.
My main concern with hard-coding credentials in the Nginx configuration is that, even in this case, anyone who can access the proxy endpoint may still be able to access the full REST API. Please correct me if my understanding is not accurate.
We have already experienced bot and attack attempts with this setup, which is why we would prefer not to continue using this structure. I would really appreciate your guidance on a more secure approach for handling this,
This is not accurate, as you can rely on nginx to add authentication to endpoints, including those served by a reverse proxy. In your nginx configuration, you can for instance attach the auth_basic directive to the location that uses proxy_pass.