Returning JSON from LUA without littering the log file

Google Groups archive
1

Hello,

I’ve been extending the base Orthanc installation with Lua scripts to meet our needs. Until now, the scripts primarily dealt with handling the anonymization and capturing internal data for storage in the sql database.

Now, I’d like to extend some of the capabilities by adding Lua scripts to return specially formatted queries as JSON for use by javascript code I serve up from a special web page. Both the web page and javascript are served out of Orthanc using the Sample Serve Folders plugin.

Until now, when I wanted to have Lua return some information, I put it in a simple print statement.

I can still do that with the JSON I’m constructing, but this has the unwanted side effect of littering my log file with the output of all the print statements generated by this particular Lua script.

Should I be wrapping these JSON in HTML headers - like if I were running Lua as a cgi script?

I realize that the Sample Serve Folders plugin is handing my web page and javascript to the embedded web server that comes with Orthanc, but it’s not clear to me that the Lua functionality behaves as a kind of CGI (is CGILua even installed?) or not.

Here’s my setup:

  • web page and javascript served up via Sample Serve Folders plugin

  • Javascript form on web page takes user input

  • Javascript calls Rest API “tools/execute-script” to run a Lua script on the server

  • Lua gathers results into a LuaTable

  • Lua returns results as print(DumpJson(LuaTable))

  • This works, but my log file is full of all these print results

Is there a better way?

Thanks,
John.

2

Hi John,

I must admit that you’re setup is very “borderline”. Calling tools/execute-script from the JS is certainly not what Lua was designed for.
Furthermore, I don’t know if your application is public or not but, by letting the tools/execute-script method open, anybody is able to execute any code on your host (like run “rm -rf /” from a lua script !)

I would strongly recommend that you build a small web-app running next to Orthanc. Your JS would call that webapp and your webapp would call Orthanc API (like your lua actually does right now).
There are plenty of small web frameworks available for that and even some in lua if you wanna reuse part of the code you’ve already written.

Br

Alain.

3

Hi Alain,

I already have my Orthanc locked down behind a proxy with authentication and url filtering both at the proxy and in Lua by way of the IncomingHttpRequest.

Your point about calling Lua to execute a malicious “rm -rf” command is a good one. However, isn’t that possible anyway in a default Orthanc setup? I mean, doesn’t exposing the restful API include exposing calls to the Lua backend via the tools/execute-script?

By web app, I suppose you mean eliminating any and all exposure of the restful API behind an application front end. Then, only the web app would have access to the API on the back end while the front facing app itself would provide no such access.

How does the Sample Serve Folders plugin fit into this? What is the point of serving up files from there? Is the idea that they too would be wrapped by the outward facing web app? They are essentially meant as extra tools for the web app rather than anything a user might see directly?

Thanks,
John.

4

Hi John,

5

Returning to this issue of web access and the rest API, it seems that the dicom-web plugin would need consideration as well.

Locking down the Orthanc HTTP server would also locks down the dicom-web access, yes? I gather from the documentation that the two are connected.

6

Hello John,

Returning to this issue of web access and the rest API, it seems that the dicom-web plugin would need consideration as well.
Locking down the Orthanc HTTP server would also locks down the dicom-web access, yes? I gather from the documentation that the two are connected.

I am unable to understand this question. Please could you rephrase it?

Sébastien-

7

Hi Sebastien,

I apologize for not being clear. I mean that because the rest API and dicom-web both appear to be negotiated by way of the same port in Orthanc, preventing access to that port would block both. So if I were to carefully wrap the API behind an interface and prevent a typical user from having direct access to the web API, I would also block access to the dicom-web interface at the same time.

By the way, I managed to get around this challenge by running the dicomweb through a separate proxy address. I manage the standard restful API through an authenticated proxy while I open the dicom-web proxy with fewer restrictions.

As an aside, I think Orthanc is a great well designed tool. Coming at this from the imaging researcher’s perspective it works so well out of the box I tend to limit my modifications to meet our specific research needs. In that regard, I’m probably not doing what you expected your intended audience to be doing.

I can say that the research medical imaging community has a real need for an easily configured stable open source PACS platform. We don’t have the financial resources or the expertise to design a web application around Orthanc or the incentive, especially when it works so well out of the box.

John.

8

Hi John,

Thanks again for the nice positive feedback :slight_smile:

If you need to block either the REST API or the DICOMweb API, but keep the other one active without using a proxy server, you can use a Lua script to filter incoming HTTP requests depending upon their URIs:
http://book.orthanc-server.com/users/lua.html#filtering-incoming-rest-requests

HTH,
Sébastien-

9

Thanks, Sebastien. I’m so accustomed to thinking of access by way of other PACS nodes in terms of the PACS port, it hadn’t occurred to me to block access to the wado portion with the incoming requests filter.

I like the proxy approach a bit better since I can tighten up the security a little more than I can with Lua screening of http headers.

Thanks,
John.