Access-Control-Allow-Origin

[marcelo...@sysline.inf.br]

Hello Mrs,

I'm starting now with Orthanc, does anyone know if you can allow "Access-Control-Allow-Origin" for ajax calls in Orthanc?

Thanks,
Marcelo

[Sébastien Jodogne]

Hello,

Orthanc acts as a HTTP server, so that AJAX calls issued from JavaScript code served from another HTTP server are forbidden by the same-origin policy [1].

To create some JavaScript application on the top of Orthanc, you have 3 possibilities:

1. Serve your HTML/JavaScript application directly through Orthanc. This is possible with the official "serve-folders" plugin that can be found in the Orthanc distribution [2].
2. Map the REST API of Orthanc at some URI of your Web server. This process for Apache and nginx is explained in the FAQ [3,4].
3. Create PHP code that wraps calls to Orthanc. This is for instance possible through the "curl" module [5].

HTH,

Sébastien-

[1] http://en.wikipedia.org/wiki/Same-origin_policy

[2] https://code.google.com/p/orthanc/source/browse/#hg%2FPlugins%2FSamples%2FServeFolders

[3] https://code.google.com/p/orthanc/wiki/FAQ#How_can_I_run_Orthanc_behind_Apache?

[4] https://code.google.com/p/orthanc/wiki/FAQ#How_can_I_run_Orthanc_behind_nginx?

[5] http://php.net/manual/en/book.curl.php

[Michael Folkerts]

Sebastien,

I am loving Orthanc, thank you for this gift. I would like to leverage the REST API from other (perhaps multiple) web apps running on at least one other server.

Apparently you can easily enable CORS by setting "Access-Control-Allow-Origin" to "*",  or perhaps a list of hostname:ports, in the response header coming from the Orthanc server.

I was digging through your code and think simply adding in the header (to all responses) is doable... what do you think?

[Sébastien Jodogne]

Hi Mickael,

Thanks for your positive feedback!

Following your suggestion, I have just added a FAQ section that explains my position about CORS:

https://orthanc.chu.ulg.ac.be/book/faq/same-origin.html

In a nutshell, I prefer not to introduce any way to bypass the same-origin policy directly into the core of Orthanc, but there exist at least 3 ways to achieve the same goal.

HTH,

Sébastien-

[michaelb...@gmail.com]

So can you please clarify this for me before I continue developing my javascript client? Does this policy mean that javascript code on a web page running on IIS on the same physical machine as the Orthanc server can't use the Orthanc RESTful interface? Like so:


$.ajax({
url: "http://localhost:8042/patients",
method: 'GET',
success:function(data) {
$("#fromAjax").html(JSON.stringify(data, null, 2));
}
});

Because it doesn't seem to work. Please let me know if this is the expected behavior.

Thank you,

Mike B.

On Friday, May 15, 2015 at 7:49:22 AM UTC-4, Sébastien Jodogne wrote:
> Hello,
>
>
> Orthanc acts as a HTTP server, so that AJAX calls issued from JavaScript code served from another HTTP server are forbidden by the same-origin policy [1].
>
>
> To create some JavaScript application on the top of Orthanc, you have 3 possibilities:

> Serve your HTML/JavaScript application directly through Orthanc. This is possible with the official "serve-folders" plugin that can be found in the Orthanc distribution [2].Map the REST API of Orthanc at some URI of your Web server. This process for Apache and nginx is explained in the FAQ [3,4].Create PHP code that wraps calls to Orthanc. This is for instance possible through the "curl" module [5].

[Thibault Nélis]

Hello,

On Tue, 2017-05-16 at 05:40 -0700, michaelb...@gmail.com wrote:
> So can you please clarify this for me before I continue developing my
> javascript client?  Does this policy mean that javascript code on a
> web page running on IIS on the same physical machine as the Orthanc
> server can't use the Orthanc RESTful interface?  Like so:
>
>
>           $.ajax({
>               url: "http://localhost:8042/patients",
>               method: 'GET', 
>                   success:function(data) {
>                       $("#fromAjax").html(JSON.stringify(data, null,
> 2));
>                   }
>           });
>
> Because it doesn't seem to work.  Please let me know if this is the
> expected behavior.

This is the expected behavior if it is running on a different port (as
that counts as a different origin), but it is possible to instruct the
user agent (browser) to allow execution of code originating from
different origins than the main document using CORS[1] or simply by
proxying the requests through a single origin.

I encourage you to review some resources on CORS to understand its
mechanics. Once you've done so, the three approaches already outlined
by Sébastien should become very intuitive. They're also documented
here[2].

[1] https://www.w3.org/TR/cors/ https://developer.mozilla.org/en-US/doc
s/Web/HTTP/Access_control_CORS
[2] http://book.orthanc-server.com/faq/same-origin.html

[Michael Bowers]

I greatly appreciate your response to this question.  One thing I found strange was that within the same web pages I'm able to use the Orthanc REST API to successfully post instances to Orthanc.

            $.ajax({

                url: "http://localhost:8042/instances",

                type: "POST",

                data: file,

                processData: false

            });

Also the expected behavior?

[Thibault Nélis]

On Thu, 2017-06-08 at 10:25 -0400, Michael Bowers wrote:
> I greatly appreciate your response to this question.  One thing I
> found strange was that within the same web pages I'm able to use the
> Orthanc REST API to successfully post instances to Orthanc.
>
>             $.ajax({
>                 url: "http://localhost:8042/instances",
>                 type: "POST",
>                 data: file,
>                 processData: false
>             });
>
> Also the expected behavior?

Only if the origin of the page/iframe within which that code runs is
localhost:8042, or if you're using a browser extension to override the
SOP (common for debugging) or if you're using a buggy/non-compliant
browser. Are any of these conditions true by any chance?

Note that you haven't actually explained the failure you're observing
when retrieving the patients list in your previous message; you merely
said "it doesn't seem to work". Are you sure this is a CORS-related
issue? Your browser should output diagnostics in the console if that's
the case.
--
Thibault Nélis <t...@osimis.io>
Osimis

[Michael Bowers]

Thanks Thilbault.

So the POST that works is in a dropbox in the "DICOM Upload" section of a page served up by the same debugging environment (Visual Studio) as the GET, not on port 8042.

It's running in Chrome.  Seems possible that POSTs and GETs might be treated differently under the same-origin policy?

So I don't get any indication of why the GET doesn't work - changed the code to:

          $("#fromAjax").html("Pre ajax call");

          $.ajax({

              url: "http://localhost:8042/patients",

              method: 'GET', 

                  success:function(data) {

                      $("#fromAjax").html(JSON.stringify(data, null, 2));

                  },

              error: function (err) {

                  $("#fromAjax").html("AJAX error in request: " + JSON.stringify(err, null, 2));

              }

          });

The error that's put out is:

AJAX error in request: { "readyState": 0, "status": 0, "statusText": "error" }

So it's definitely trapping an error, but there's not much information returned.  Nothing significant in the Output window.  I actually don't know if it's a CORs related issue.  Would be happy to try other ways to gather more error information.

Thanks again for the help.

Mike B.

[Sébastien Jodogne]

Hello,

Please use the debugging tools that are built in Chrome: Just hit "F12", and you will have more information about why the AJAX query fails.

Obviously, the Orthanc project cannot provide any support for a Web application such as "Oncospace" you are building by yourself on the top of Orthanc.

Regards,

Sébastien-

On Monday, June 12, 2017 at 6:12:44 PM UTC+2, Michael Bowers wrote:

So the POST that works is in a dropbox in the "DICOM Upload" section of a page served up by the same debugging environment (Visual Studio) as the GET, not on port 8042. [...] So it's definitely trapping an error, but there's not much information returned.  Nothing significant in the Output window.  I actually don't know if it's a CORs related issue.  Would be happy to try other ways to gather more error information.

[Michael Bowers]

Ha - thanks.

Oncospace is a data store of the complete radiotherapy experience for providers and patients.  It's been in use since 2007 - it's not built on Orthanc.  We need some client-side DICOM functionality to help us streamline a part of our clinical workflow, and to support multi-institutional research.  We were hoping not to re-invent the wheel.

But sometimes, that's what you have to do...

Thanks again, Sébastien and Thibault

[Michael Folkerts]

I've used ORTHANC for clinical workflows... Try looking at the "network" tab in developer tools when running the browser and attempting the drag and drop upload (sometimes I've gotten an error if the files I am dragging and dropping are on a network drive... Could that be it?) ... There are also ways to NOT use a browser but still automate uploads and workflows (the Python scripting examples).

--

--
Michael M. Folkerts, Ph.D. Candidate
(Sent from Android via Inbox)