Jump to content

Biggeveen

Members
  • Posts

    7
  • Joined

  • Last visited

Posts posted by Biggeveen

  1. I'm trying to get NI's API Key Security working to restrict access to a Webservice. (...)

    The point is, even if I enable API Key security and configure the keys, it is still possible to request the page and get the data without supplying the keys.

    I contacted National Instruments about this, they acknowledge the bug. They also told me it is likely not going to be fixed in the next release, and probably the entire API Key mechanism will be removed in future versions...

  2. Dear folks,

    I'm trying to get NI's API Key Security working to restrict access to a Webservice. I'm using Labview 2010 32-bit with f2 patch on English Windows 7 Professional 64-bit. Until now my attempts are unsuccessful.

    My idea of API Key Security is the following:

    Client requests an URL Mapping at the NI Webserver for which API Key security was enabled in the build.

    If the right API Key headers are supplied, the webserver returns code 200 and the data.

    If wrong or no API Key headers are supplied, webserver returns 403 access denied and no data.

    The point is, even if I enable API Key security and configure the keys, it is still possible to request the page and get the data without supplying the keys.

    I created a small test project which you can run on your computer, I have attached it.

    So I did the following.

    1) configured NI Application Webserver to run on port 80 (you can do this here).

    2) Created a VI "test.vi" which outputs a test message (current date and time followed by 'congratulations').

    3) created "apikeytest" webservice for this VI, enabled API Key security for the URL mapping, built an deployed it to localhost.

    4) configured NI Distributed System Manager (DSM) to show webservices (instructions), it doesn't do this by default.

    5) configured the following API Key using NI DSM: accessID=api, secureID=key, see attachment.

    6) restarted webservices (Start > Run > services.msc > restart "NI Application Webserver")

    If I now make a GET request to http://localhost:80/apikeytest/test using attached "http get client.vi", or a normal browser, you always get HTTP Status 200 OK and the data, no matter if the keys are added or not.

    Removing the apikeytest webservice using DSM prior to deploying a fresh build doesn't help.

    I found RESTclient add-on for Firefox very useful to see which headers are sent and received.

    So it seems the webserver doesn't know that he has to validate API Keys, although I enabled it in the build configuration and configured an AccessID and SecretID.

    Anybody any suggestions how to get this running?

    Don't be suprised if I do not reply before 3 January!

    post-18473-0-33400300-1293103597_thumb.p

    api key test20101223.zip

  3. Well, seems srvany.exe does work on Windows Server 2008 R2 although it is not designed for it. I copied srvany.exe and instsrv.exe from the Windows XP box. I didn't try sc.exe jet because I had srvany.exe ready with some GUI to call it.

    By the way, the srvany and our variable initialisation exe are 32-bit apps on a 64-bit Server 2008 R2, seems not to give problems (we don't need >2GB of memory jet and development is currently on Windows XP 32-bit system).

    The only thing is that requests like sc stop (probably equal to undeploying the variables) and sc pause are not handled currently, srvany simply kills the labview exe. This is something to be solved. Also srvany is not supported by Microsoft (on any OS), which is a disadvantage too. Switching to sc.exe or similar is to be considered.

    Kuan Chen wrote a guide how to create a Labview service (link one, two and three). It involves some C code and DLL stuff I'm not familiar with, note this was written in 2005 so maybe things changed...

  4. Dear all,

    I've got a question regarding networked variables combined with Web Services, how to load these variables from a file at boot. I'm not sure if this is the right place as I'm new to Lava.

    Our problem is the following, I hope some more experienced programmer can give me some hints in the right direction. Any help would be great.

    The application consists of some RESTful web service vi's which are called using HTTP and a Labview management program. All this uses the same shared variables so they are of the type Network-published shared variable (see this thread). Some configuration is stored in the variables and this is edited using the Labview program. When a configuration change is made, the variables are written to an XML file, works ok. The web VI's read and write also to these variables but their values do not need to be saved when the machine is rebooted so they are not saved in XML.

    The web service currently runs on LabVIEW 2010 on a Windows Server 2008 R2 system, finally the application should run using only the LV2010 runtime and NI web server.

    What I want to do is read the XML at boot into the shared variables so I'm sure the configuration is read in correctly. I have a VI to do this. This initialization has to be done before the first HTTP call to a VI is made, so at boot time when the NI web server starts.

    On Windows XP I could compile the initialization VI to a Labview exe and run it as a service using srvany.exe (tool from Microsoft), no problem. However in Windows 7 and Windows Server 2008 srvany.exe has gone.

    Does anybody have an idea how to create a Labview exe which is compatible with windows services, and can be installed using sc.exe? By putting the load VI in the service exe the initialization problem would be solved.

    As far as I know a service exe needs to response to certain start / stop / reload calls issued by the service manager.

    One other solution is to make the web VIs check if the configuration is loaded and else execute the initialization VI, but this is - with about 10 web VIs - a bit a dirty solution...

    Any ideas would be welcome...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.