LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Options for file transfer to network share

As part of an automated software update fearture I'm writing for our manufacting test code, I'm exploring ways to transfer files between test stations and a Windows network share.

 

My current approach is to programatically map a drive to the network share, and then there's a 1-to-1 mapping of file paths for the file copies, byt changing the drive letters of the paths. This leaves a mapped drive open on each tester, which is a potential security risk, and although this can be closed at the end of the operation, I thought I should explore other options.

 

Ftp and Web DAV (which I have no experience with) may be options, but seem to require additional setup steps. What other options should I explore?

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 1 of 10
(4,862 Views)

For me the LabVIEW FTP palette has worked well if I want to save records off disk without a network share and I see it as adequate in terms of security for the LAN but if you want to send records across the WAN then you might like to look at one of the third party SSH/SFTP libraries.   

 

Greg Payne has produced one here http://www.labvolution.com/sftp-file-transfer-labview/ or there's another here http://sine.ni.com/nips/cds/view/p/lang/en/nid/210882.  I haven't used either of these but I imagine that Greg's will be very straightforward to deploy.

 

Have fun.

Simon

0 Kudos
Message 2 of 10
(4,816 Views)

What's wrong with treating the Windows Network Share as an "ordinary device"?  I cobbled together the following demo just now:

Write Share.png

which, when run, had last mod = 8:02:02.000 AM, 2/14/2017, and produced Write Share Output.png

The "security risks" are no different than doing any other sort of file I/O -- you need read/write privileges on the Share, which are presumably controlled by your User credentials.  No muss, no fuss.

 

Bob Schor

0 Kudos
Message 3 of 10
(4,801 Views)
@Bob_Schor wrote:

 

The "security risks" are no different than doing any other sort of file I/O -- you need read/write privileges on the Share, which are presumably controlled by your User credentials.  No muss, no fuss.


I agree that this is the way it has been done for years Bob, but it's not in any way secure and much of industry is waking up to the need to do it better.  Your example suggests that your file share is completley open (unless the computer is on the same domain as the file server) and so any hacker on the inside of your firewall could have a field day. 

 

The use of FTP and SFTP is in my opinion a better way to secure data in transit and carries very little overhead in programmatic terms.  It can also be far more resilient than a simple file share.

 

 

0 Kudos
Message 4 of 10
(4,792 Views)

Sipic wrote:

Your example suggests that your file share is completley open (unless the computer is on the same domain as the file server) and so any hacker on the inside of your firewall could have a field day. 


My solution was to leave the share closed but programmatically execute a net use command to send credentials. While there are still some security risks with this approach it is much simpler to use and maintain than FTP and is still better than an open drive or a fully mapped drive.

0 Kudos
Message 5 of 10
(4,784 Views)

You cannot even see the Share unless your Domain Credentials grant you access to the Server's OU, and even then, your Read, Write, and Delete privileges are controlled by Active Directory.  Not to mention being behind a pretty strictly-controlled firewall.

 

I was assuming (perhaps in error) that the Original Poster was working within a controlled environment (mentioning Test Stations and a Windows Network Share).  If the Network Share is "wide open" to the world, then all bets are off.  Otherwise, my "simple" approach seems quick and reasonable ...

 

Bob Schor

0 Kudos
Message 6 of 10
(4,768 Views)

Your caveats re-inforce the point Bob in that in this age, even if we are within the safety of the corporate domain we shouldn't be assuming that our networks are secure.  It is so easy to connect ad-hoc access devices to the corporate infrastructure that it falls on us as developers not to look for the 'simple' solution but the secure one.  

 

Who is it that said 'Assumption is the mother of all f'ups.'  Nuff said.

 

0 Kudos
Message 7 of 10
(4,760 Views)

Dear BowenM,

 

This discussion has given me some good ideas. I was not aware that I could send credentials using NET USE without mapping a drive, and then doing a direct copy using the full share path. I would prefer this route to fully mapping the drive. Thanks!!!

 

Now, I need ot do some homework on NET USE for this purpose.

_____________
Creator of the BundleMagic plugin for LabVIEW!
Message 8 of 10
(4,755 Views)

@littlesphaeroid wrote:

Dear BowenM,

 

Now, I need ot do some homework on NET USE for this purpose.


net use \\server\share password /user:username /persistent:yes

 

The biggest security risk here is you have to store the password in a file somewhere or hardcode it and assume it never changes.

 

Or... you can have the command execute with the task scheduler on user login or something.

0 Kudos
Message 9 of 10
(4,744 Views)

@Sipic wrote:

Your caveats re-inforce the point Bob in that in this age, even if we are within the safety of the corporate domain we shouldn't be assuming that our networks are secure.  It is so easy to connect ad-hoc access devices to the corporate infrastructure that it falls on us as developers not to look for the 'simple' solution but the secure one.  

 

Who is it that said 'Assumption is the mother of all f'ups.'  Nuff said.

 


A share can be limited to specific users and computers, so ad-hoc devices shouldn't be a problem. By the same logic you can't use FTP either since it can be snooped, or something.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 10 of 10
(4,722 Views)