Using htaccess to secure front panels

[Arcus111]

I am trying to secure the LabVIEW web server using simple htaccess. I have tried creating this file as htaccess.txt and .htaccess. I can't get either one to work. Is this feature still supported in the web server that is shipped with 2015?

[Sam_Sharp]

NI has it's own authentication for Web Services which can be configured from the Web-based configuration tool, there is a guide on how to do that here: http://digital.ni.com/public.nsf/allkb/DF41D5DA8EEB4840862577D90058C208

For configuration authentication for remote front panels, there is a guide here: http://digital.ni.com/public.nsf/allkb/C70EF64F0B259C2F8625740000705673

It looks like it cannot be done for built executables with remote panels - but the file should htaccess.txt, once you have configured it in the development environment.

If you want to secure a remote front panel in a built executable, you will probably need to build in your own authentication into your VI (e.g. have a username and password field).

[Arcus111]

Thanks for the info. I have read over that and the other recommended documents for adding remote front panel authentication. The officially recommended scheme has some problems. Because the mechanism relies on adding browsers and VIs to the web server's allowed list, it can open those remote panels up to other users behind the same firewall. It also does not manage multiple simultaneous user access very well. This also becomes extremely cumbersome when running multiple front panel windows.

The simplest solution is to just secure the access from the web server side. But I can't find any support for doing this in the LabVIEW Web Server. If I could serve the front panels through Apache or IIS, I could easily add security via HTTP authentication using ASP or PHP. The best solution I can think of requires recreating the front panels in HTML and using a communication protocol, syncronize UI updates between the HTML and front panel. But that will require a lot of work. I was just hoping for an easy layer to hook into or a wrapper to apply around the HTML or front panels. Surely this is something other people have requested. Having support for this great feature for over a decade, you would think that National Intruments would have a decent solution in place to secure everything.

[Sam_Sharp]

I think you can do that....instead of using the built-in LabVIEW web server I think you can just take the html files, open them locally as files and/or host them on another web server.

When you go to the web-publishing tool, one of the options is 'local directory to save the web page' - just copy the files from there and put them in the public folder of another web server (e.g. Apache).

I'm pretty sure it'll need to reside on the same machine as it looks like the 'target' information for the remote front panel seems to embedded in the html code.

(Actually, now that I'm thinking about it - I'm not so sure...but it might be worth a try)

[Arcus111]

Thanks for the suggestion. I considered this option from the following articles:

http://zone.ni.com/reference/en-XX/help/371361E-01/lvhowto/embed_vi_in_html_doc/

http://digital.ni.com/public.nsf/allkb/4A749D8AAECEC169C1256C9C00584CF9

But I also came across someone who had tried to do it before:

http://forums.ni.com/t5/LabVIEW/Remote-Web-Panels-on-Apache-instead-of-LabVIEW-Web-Server/td-p/67613...

They didn't have much success. Wrapping IIS or Apache around the existing LabVIEW Web Server doesn't really fix the issues with security because it is just embedding the link to the existing web server, so no matter how much the IIS/Apache server is secured, the LabVIEW Web Server remains publicly accessible and open to security vulnerabilities.

I think I am going to have to re-architect everything to use Web Services for communictions and just use existing web controls or maybe integrate with Web UI Builder. Seems like a lot of work to just provide a little security to a feature that already works really well and fits my needs nicely.

[mcduff]

Have you seen this link

https://lavag.org/topic/19236-turn-your-front-panel-into-an-interactive-html5-site/

it may be of some use to you.

Cheers,

mcduff

[Sam_Sharp]

Ah, I didn't realise it was that restrictive - I thought you could host/open the web-page itself anywhere and the plugin was clever enough to control access.

---

@Arcus111 wrote:

I think I am going to have to re-architect everything to use Web Services for communictions and just use existing web controls or maybe integrate with Web UI Builder. Seems like a lot of work to just provide a little security to a feature that already works really well and fits my needs nicely.

---

Trust me, it will be worth the effort. Considering that remote front panels require the LabVIEW Runtime Engine to be installed on every PC that wants to access it, the plugin has to be installed, the fact that the plugins no longer work in Chrome and Edge browsers etc., the security issues you've identified, little support/improvements to the technology from NI it doesn't make sense to use them in new applications. If you did really want to use them, you could secure the VI itself with some sort of password authentication on the VI itself to enable the controls/indicators.

We actually decided to move over to WebSockets for accessing/controlling VIs remotely - take a look at the links in my signature for some guidelines on what can be done - including a 'chat' example. You could also take a look at LabSockets - a 3rd party toolkit that works in a similar way to remote front panels but is based on websockets. LabVIEW Web Services are another option but they're not as 'immediate' (you can only poll for data via HTTP).

I suspect a future version of remote front panels would do something similar.