Restrict access to a LV web services web page

[ChrisClark]

I want to restrict access to a web page that displays live data from a LV web service. Should I use authenticated HTTP requests as described in tutorial 7749, LabVIEW Web Services Security? If so, do I need to use scripting in the web browser client to create the HTTP request? The tutorial just describes a client app, not a browser.

Or is there some other way to do this, like just logging in to a service with an ID and a password on the first request.

Or would it be easier to achieve this goal by using Remote Panels? Thanks.

cc

[GoGators]

Or is there some other way to do this, like just logging in to a service with an ID and a password on the first request.

Or would it be easier to achieve this goal by using Remote Panels? Thanks.

cc

Not sure about what version you are using, but in LV2010 there are ways to assign NI-Auth parameters to each of the web methods. It is in the web services build under the "URL mappings" section. That is by far the easiest. But the browser would have to have silverlight, which the NI-Auth client uses.

[Rob Calhoun]

I want to restrict access to a web page that displays live data from a LV web service. Should I use authenticated HTTP requests as described in tutorial 7749, LabVIEW Web Services Security? If so, do I need to use scripting in the web browser client to create the HTTP request? The tutorial just describes a client app, not a browser.

Or is there some other way to do this, like just logging in to a service with an ID and a password on the first request.

Or would it be easier to achieve this goal by using Remote Panels? Thanks.

cc

For reference Chris is referring to this tutorial: Tutorial 7749

The NI security model is weird. I looked into it and decided it was focused almost exclusively on granting access to an application rather than to a user in a browser. (I mean, sure, you could write javascript to generate the hash from security keys embedded in the javascript, but given that the javascript code is in plain sight, what is the sense in that?)

What I ended up doing was using IIS and ASP for most of the web stuff. When I needed something LabView-specific, I used IIS as a proxy server. (Client authenticates with and talks to IIS on port 80; IIS talks to the LabView web server on port 8000; the LV web server is configured to only take requests from localhost, and port 8000 blocked to external users.) This way you get all of the various ways that authentication can be done with IIS (such as domain security); you could even do SSL. It's pretty easy; from the ASP app you just take apart the URL and rebuild it, repoint it to localhost:8000, then have the ASP app make an HTTP request to LabView and spit back whatever it gets to the caller. (I just used ASP instead of ASP.NET because I'm lame; don't do that, it's totally obsolete. :-)

This works great, but doesn't seem like a good fit for live data. (How does LabView send live data anyway? Via asynchronous XMLHttpRequests?) How about this twist on what I made fun of in the first paragraph: write javascript that generates the required hash from the NI security code, and store it in an IIS-served directory. It's a pretty crummy security model, in that a user with read access could just save the javascript and do whatever with it, but if this is a read-only situation behind a firewall that is perhaps tolerable.

In general I did not find working with LabView web services to be a lot of fun. There were lots of difficult-to-isolate bugs in it, like their default deployment generating pathnames that are longer than 255 characters, which Windows can't handle (see ). Hopefully things are better under LabView 2010.

[Rob Calhoun]

What I ended up doing was using IIS and ASP for most of the web stuff. When I needed something LabView-specific, I used IIS as a proxy server...

So it turns out this is called a reverse proxy server and there are a wide number of free and commercial implementations. If your web service will still work through the proxy, this is a good solution.