Does the Sample Serve Folders plugin provide the capability to serve up CGI scripts (say, lua) and thus permit dynamic page generation? This capability seems to be implied in the discussions about the same origin policy and javascript access to the Rest API.
I’ve used the plugin to serve static html files, albeit ones I generate with the LUA scripting hooks in Orthanc.
However, I’d like to create some web forms that would subsequently call back end CGI scripts for processing to generate dynamic html in response. Is that possible using the plugin here?
On a related issue, regarding the same origin policy and javascript, I find I still run into origin violation errors when I serve up html with embedded javascript from the plugin folders. So, for example, the javascript within the html file I serve from the plugin folder still cannot call the API without running into the same origin violation. I’m probably being dense here, but I thought the documentation implied that script served up by way of the plugin folder would work. The subtleties of CORS and the same origin policy seem tricky to me.
I see from a previous question of mine that one possibility involves writing a back end plugin in c/c++ to do the job.
I guess I could do a lot of stuff in the client browser in javascript, but I’d be back to the same-origin question I mentioned and how javascript can be served from the plugin folders to get around the same origin policy.
At this point, my solution to the same origin problem has been to run through an Apache proxy and handle it there. It might be cleaner if I could figure out how to serve javascript correctly from the plugin folders.
I have the rather complicated case of running Orthanc inside a Docker container on its own Docker virtual network fronted by the Apache proxy of the host machine running Docker. So there’s a fare amount of re-routing going on that may confuse the same-origin restrictions. However, the built-in Orthanc explorer interface seems to have no problem at all, and I got the feeling that that was largely implemented in javascript. Why the javascript I place in files served out of the plugin folder runs into problems is a mystery to me.
The reverse proxy is also a nice solution to avoid CORS issues.
Concerning cgi scripts, no, Orthanc will not run them. You should have a webserver running next to Orthanc to serve these cgi scripts. If needed, the webserver can request the Orthanc REST API directly (CORS issues only occurs inside browsers, not when using a scripting language).
I was able to get my javascript working without CORS violations late yesterday, though I’m not entirely sure what changes I made fixed the situation. Originally, I had some sections within the body of the html file being served from the plugins folder. I moved all of my javascript to a separate *js file in the plugins folder and then inserted it within the section of the html page. One of those steps must have fixed the CORS problem I was seeing.
I think that I may be able to get away with javascript for now and accomplish what I want with forms in the client browser. Otherwise, I’ll look into running the CGI in parallel either on the host Apache or some other server associated with my Docker instance of Orthanc.
My situation is further complicated by additional server redirects through our institution’s CAS single sign on service. Now that I’m watching the javascript console in the browser, I sometimes see same-origin errors for the base Orthanc explorer. That’s not Orthanc’s problem but a side effect of our institution’s single sign on, I believe.
My situation is further complicated by additional server redirects
through our institution's CAS single sign on service. Now that I'm
watching the javascript console in the browser, I sometimes see same-
origin errors for the base Orthanc explorer. That's not Orthanc's
problem but a side effect of our institution's single sign on, I
believe.
Neither redirects, script tag placement within HTML resources nor the
request line (everything after the hostname in the URI) should impact
CORS (as far as I can tell).
CORS lets the server give the client a list of known origins (scheme +
host + port) that the client should trust a script to connect to (via
XHR/fetch and other restricted APIs); in effect bypassing the same-
origin policy. In other words, one of your scripts is trying to connect
to a different origin than the one the HTML page was served from.
Returning to this very old topic, I finally seem to have resolved some of the CORS issues I was running into when employing my institutions single sign on (SSO) service.
The issue was only tangentially related to Orthanc and mostly due the interaction between the Apache server that I employ to proxy my Orthancs and the mod_auth_cas module used to authenticate against the institution’s SSO. It was necessary to add a CASScope to the Apache proxied Location/Directory I used to proxy the Orthancs.
Without the CASScope variable, for reasons I still do not quite understand, the back and forth between the SSO and the proxied Orthanc would sometimes drop parts of the proxied URL, leading to the browser thinking there was a CORS violation.
Another side effect of my particular SSO/Apache proxied Orthanc setup was that the missing CASScope led to too many round trip queries that would ultimely timeout the page.
For some reason, fixing the CASScope issue has eliminated the CORS errors I was seeing.