For security reasons, I need to run a Shiny app on an internal server. I am able to talk to IT about getting it there, but I am one of two people at my company who use R, so IT has never come across this situation before.
I have been looking online for ways to support a shiny app internally, but I have not been able to really find anything useful that has been posted recently. I know R changes frequently and is constantly improving, so articles from 2010 or 2014 aren't as helpful as I'd like.
I am looking for information I can bring to my IT department to help them get my app onto the internal server without them having to do a lot of research into R.
The answer very much depends on your needs, depending on the complexity of the app and the number of simultaneous users. Since this is only internal, you may not need to go through the lengths described in Pork Chop's comment.
In the most basic instance, you can load RStudio on an existing server and use runApp (the normal way of initializing a shiny app). In the top left corner you will see an internal http address, as well as an "Open in Browser" button. Any user connected to the server can navigate to the internal address and use the app. If you are unlikely to have concurrent users, and don't mind dedicating an RStudio instance to the app, then this is the easiest way for IT to deal with it. Note that this implementation is very limited.
The next level up would be an open source Shiny Server Community Edition, which is free to use. The process to set it up is more complex, but is covered here: http://docs.rstudio.com/shiny-server/ Please note that this is the documentation for the pro version, however I believe that it is the same documentation for the open source version. All of the open source guides link to it on shinyapps.io. To download Shiny Server Community Edition visit here: https://www.rstudio.com/products/shiny/download-server/ or you can look at the differences in products here: https://www.rstudio.com/products/shiny/shiny-server/
Related
I have created an R code script that:
Reads some data from a database
Makes some transformations and..
exports into a csv the modified table.
This code needs to run in a client's machine, but we need to "hide" the actual code from the user.
Is there any useful suggestions on how we can achieve that?
Up front
... it will be nearly impossible to deploy an R <something> to another computer in a way that prevents curious users from accessing the source code.
From a mailing list conversation in 2011, in response to "I would not like anyone to be able to read the code.",
R is an open source project, so providing ways for you to do this is not
one of our goals.
Duncan Murdoch https://stat.ethz.ch/pipermail/r-help/2011-July/282755.html
(Prof Murdoch was on the R Core Team and R Foundation for many years.)
Background
Several (many?) programming languages provide the ability to compile a script or program into an executable, the .exe you reference. For example, python has tools like py2exe and PyInstaller. The tools range from merely compactifying the script into a zip-ball, perhaps obfuscating the script; ... to actually creating a exe with the script either tightly embedded or such. (This part could use some more citations/research.)
This is usually good enough for many people, by keeping the honest out. I say it that way because all you need to do is google phrases like decompile py2exe and you'll find tools, howtos, tutorials, etc, whose intent might be honestly trying to help somebody recover lost code. Regardless of the intentions, they will only slow curious users.
Unfortunately, there are no tools that do this easily for R.
There are tools with the intent of making it easy for non-R-users to use R-based tools. For instance, RInno and DesktopDeployR are two tools with the intent of creating Windows (no mac/linux) installers that support R or R/shiny tools. But the intent of tools like this is to facilitate the IT tasks involved with getting a user/client to install and maintain R on their computer, not with protecting the code that it runs.
Constrain R.exe?
There have been questions (elsewhere?) that ask if they can modify the R interpreter itself so that it does not do everything it is intended to do. For instance, one could redefine base::print in such a way that functions' contents cannot be dumped, and debug doesn't show the code it's about to execute, and perhaps several other protective steps.
There are a few problems with this approach:
There is always another way to get at a function's contents. Even if you stop print.default and the debugger from doing this, there are others ways to get to the functions (body(.), for one). How many of these rabbit holes do you feel you will accurately traverse, get them all ... with no adverse effect on normal R code?
Even if you feel you can get to them all, are you encrypting the source .R files that contain your proprietary content? Okay, encrypting is good, except you need to decrypt the contents somehow. Many tools that have encrypted contents do so to thwart reverse-engineering, so they also embed (obfuscatedly, of course) the decryption key in the application itself. Just give it time, somebody will find and extract it.
You might think that you can download the key on start-up (not stored within the app), so that the code is decrypted in real-time. Sorry, network sniffers will get the key. Even if you retrieve it over https://, tools such as https://mitmproxy.org/ will render this step much less effective.
Let's say you have recompiled R to mask print and such, have a way to distribute source code encrypted, and are able to decrypt it in a way that does not easily reveal the key (for full decryption of the source code files). While it takes a dedicated user to wade through everything above to get to the source code, none of the above steps are required: they may legally compel you to release your changes to the R interpreter itself (that you put in place to prevent printing function contents). This doesn't reveal your source code, but it will reveal many of your methods, which might be sufficient. (Or just the risk of legal costs.)
R is GPL, and that means that anything that links to it is also "tainted" with the GPL. This means that anything compiled with Rcpp, for instance, will also be constrained/liberated (your choice) by the GPL. This includes thoughts of using RInside: it is also GPL (>= 2).
To do it without touching the GPL, you'd need to write your interpreter (relatively from scratch, likely) without code from the R project.
Alternatives
Ultimately, if you want to release R-based utilities/apps/functionality to clients, the only sure-fire way to allow them to use your code without seeing it is to ... control the computers on which R will run (and source code will reside). I'll add more links supporting this claim as I find them, but a small start:
https://stat.ethz.ch/pipermail/r-help/2011-July/282717.html
https://www.researchgate.net/post/How_to_make_invisible_the_R_code
Options include anything that keeps the R code and R interpreter completely under your control. Simple examples:
Shiny apps, self-hosted (or on shinyapps.io if you trust their security); servers include Shiny Server (both free and commercial versions), RStudio Connect (commercial only), and ShinyProxy. (The list is not known to be exclusive.)
Rplumber is an API server, not a shiny server. The intent is for single HTTP(s) endpoint calls, possibly authenticated, supporting whatever HTTP supports (post, get, etc). This can be served in various ways, see its hosting page for options.
Rserve. I know less about this, but from what I've experienced with it, I've not had as much luck integrating with enterprise systems (where, e.g., authentication and fine-control over authorization is important). This does allow near-raw access to R, so it might not be what you want (especially when the intent is to give to clients who may not be strong R users themselves).
OpenCPU should be discussed, but not as a viable candidate for "protect your code". It is very similar to rplumber in that it provides HTTP endpoints, but it supports endpoints for every exported function in every package installed in its R library. This includes the base package, so it is not at all difficult to get the source code of any function that you could get on the R console. I believe this is a design feature, even if it is perfectly at odds with your intent to protect your code.
Anything that can call R or Rscript. This might be PHP or mod_python or similar. Any web-page serving language that can exec("/usr/bin/Rscript",...) can take its output and turn it around to the calling agent. (It might also be possible, for example, for a PHP front-end to call an opencpu endpoint that only permits connections from the PHP-serving host.)
i try to find a good combination of libraries for managing a real-time communication (client/server) using Haxe (only Haxe, not openfl or other framework base on Haxe) targeting flash (swf) for the client and no preference for the server except don't use neko.
The goal is to make a simple tchat and put a display representation of all clients on an aera. Each client can move his representation in this area, and the other sees the movement.
I find some Lib to make this :
https://github.com/soywiz/haxe-ws
https://github.com/MattTuttle/hxnet
haxe-js-kit
But I'm not sure of the best way to adopt.
Do you have any suggestion/remarks/tips to choose the better way ?
Disclaimer: I wrote the library that I am sharing here.
My somewhat new library mphx may be able to help you. It can manage 'rooms' of connections, allows client to server and server to client messaging in the form of events, and best of all, is cross platform. It also works in the web with websockets.
It was originally an extention of HxNet, however I wanted it to be easier to use. Connecting and sending a 'message' with data just takes a few lines.
I have a few examples in the github repository, the simplest being the 'basic' example. One of your requests you have is that it doesn't rely on one of the big libraries (open fl, etc) and mphx doesn't. The basic example proves that, and only runs in terminal. That being said, it can be used with haxeflixel, for that you can see the other examples.
It sounds like your main goal is to have simple, graphic multiplayer. For that you can look at the 'movement' haxeflixel example.
Documentation is still a little skim, and the code is alpha, so it might change or break. That can probably be said for most of the library's you listed though. The best way to install it is like this
haxelib git mphx https://github.com/5Mixer/mphx.git
That will not install the examples though. To run them, either download the repository as a zip, or just git clone it, and go into the examples folder.
Library: https://github.com/5Mixer/mphx
Old video's I made. A little outdated, most likely.
Video 1: https://www.youtube.com/watch?v=07J0wLXwH0g
Video 2: https://www.youtube.com/watch?v=MUx2CUtsnTU
I can not avoid windows at work. As such, I have a second machine that I use to do all of my heavy lifting and data analysis. In an ideal world, I could create a Shiny app and access it from another computer on my work's local network.
The solution that my IT folks proposed was using Remote Desktop, which COULD work, but I don't really want other users locking the machine.
Does anyone have insight as to how I can allow computers on my network to view my Shiny apps? I should have admin rights on my 2nd machine in case I need to tweak a few settings.
EDIT: While my ideal use case is Shiny, I would also want to access other R-based reports like Slidify presentations, compiled R Markdown reports, and perhaps, Gitbooks compiled to stand-alone websites.
Thanks in advance.
It should be sufficient to set the host argument to 0.0.0.0 to allow it to broadcast beyond localhost, e.g.
runApp("app_name",host="0.0.0.0",port=3168)
Then you can visit http://machine2DNSname:3168 to see it.
I've got a Windows 2008 Enterprise R2 Server running Ektron 8.02 SP3 that is causing me some trouble that I can't diagnose.
So my question isn't for a solution but simply how to better profile a .net application / windows server. Whenever you try to POST a form built by the software, it takes 8 seconds and change to return the page (on this specific server, it doesn't do it on other machines with the same codebase). It appears that it's trying to make a connection to something for 8 seconds, fails, then returns the page without error. Some more facts:
This is a beefy VM that is not being over utilized
The database is running on the same machine, so there is no lag there.
The 8 second delay even happens when submitting from the server itself
The event viewer for the server doesn't report any errors that seem related
Profile MSSQL doesn't report any issues either
Microsoft Network Monitor doesn't report any glaring networking issues, though its hard to say as the tool doesn't report long connection attempts clearly (from what I've seen of it)
I feel sufficiently confident that there is some process during the form POST on the server that is trying to make a connection somewhere, failing, and continue through the rest of the process. It doesn't report any errors and the forms all submit fine.
So, all that being said, is there anything else I can do to debug this? I feel like I'm shooting in the dark. Thanks for any help you can offer.
It sounds like this isn't an application you wrote. If so, the potential solutions are different.
A first level step would be to use Windows' Performance Monitor. Select the options (process and/or performance attribute to watch), then run the process through its paces.
If Performance Monitor can't help, you'll need to get into the real guts of the app. Most likely this will be more difficult than you want unless you're writing the app. You can debug a .NET app that is not your own using Reflector (paid) or ILSpy (free). HOWEVER, this can violate the license agreement (and likely does if the app has been purchased).
Apart from that, you're going to need to contact the product developer if you want to both stay sane and find this problem quickly.
Our company is using some software that ONLY accepts input from an "Imaging Device" i.e. a TWAIN device (e.g. scanner).
The problem is that we are receiving our files digitally, so using an actual scanner would require us to print, scan, and shred documents that we already have on the computer, but not in the software.
I was curious if anybody has any idea of how we might be able to work around this problem in the meantime. My first thought was to find some way to trick the program into thinking we're using a scanner, via some new 'imaging device' that would just read in the file, and spit it out to the software, but I don't even know where to begin with that.
We put in a feature request, seeing as how this problem should obviously be addressed in the software itself, but the company is notorious for lagging pretty hard when it comes to updates.
The system used by scanners is called TWAIN, so you'd be looking for some sort of virtual twain driver.
A quick google search will produce several hits, I don't have any experience with the software myself so can't advise any further.
Two such providers I found via experts exchange:
http://www.twaintools.de
http://www.scanpoint-usa.com
OK, months late... but in case you are interested, I have a TWAIN driver framework/toolkit that might let you build this fairly easily, depending on just what your scanning app expects, and how hard it is to read images from your digital documents. It's a Microsoft Visual C++ project. No charge but you'd need our permission to redistribute a driver based on it: GenDS
The TWAIN Working Group also has a sample/skeleton driver, I think it's straight C - and used to have some rather bad bugs (Why I wrote mine ;-) but, it might have got better.
Look for the "sample data source and application" on their download page.
And of course I have a 'commercial' version of GenDS that I use to write TWAIN drivers on contract.