Hi all,
I would like to know what others are doing to protect their scripts as corporate IP, and whether groups are logging script usage. Script logging is good to see which are our most broadly used scripts and we can target efforts accordingly.
Our present method is to log encrypted script usage to a network drive, which requires that a user is already authenticated on the network. If the JMP script cannot access the network drive, the script terminates. If it can, it logs script usage information such as script name, username, and date/time by writing a text file to the network directory. The time to do this is fairly long, sometimes more than 10s, depending on user location vs the server and whatever network conditions may exist. I think most of it is the file write operation. From the user perspective, this isn't great... it appears that JMP is spending an inordinate amount of time trying to open the scripts' GUIs, but really it is time spent connecting to the server and writing the file. I can't solve our network issues, and I have some workaround ideas, but I'd like to see if any of you have alternative suggestions after reading through this.
Note: We encrypt our scripts to view, but we do not encrypt our scripts to run them.
Current:
- Run script
- Check if network path exists
- if it exists, log usage info (takes a lot of time) and continue with script. Use save text file() command with text in a csv.
- This accomplishes both verifying authentication and logging usage. If we only needed verifying authentication, simply checking whether the directory exists would suffice, and seems to be pretty fast.
- Else, terminate script
Proposal 1:
- Run script
- If authentication_namespace does not exist (first time verifying authentication within JMP session)
- Note: "authentication_namespace" here refers to a namespace that can be created and variables created within it. Any script in a JMP session can check to see whether it has been created, or if it does not yet exist. We can use this to create this namespace after authentication
- If network directory exists, (verify user is on company network)
- create the authentication_namespace. We could create a variable within it, but I don't think we need to. We'll just verify its existence later.
- Locate local logging file and upload all previously locally logged script usage data to the server.
- Doing this only during authentication at least cuts down the time spent writing to once per JMP session
- Problems: How many files to pick through? I'd keep it in a 'log' folder in the default directory to limit it to our log files, but what if there's a corrupt file? Or if it gets opened separately by a user? or if a user double clicks on a script and multiple files get created with the same time stamp (which is most recent)? Or if there's multiple sessions of JMP open? A future JMP session won't have access to the namespace's reference, only the name we give it. etc, etc.
- If network directory does not exist, terminate, as user is not on the network
- If authentication_namespace exists (user has been previously verified as authenticated within this JMP session), log usage locally to default directory \ log folder.
- if file does not exist, create it and save log info
- if file exists, append log info
- (note caveat outlined above, multiple files, etc)
- No need to transfer the information to the server now, do that only when verifying authentication the first time within the JMP session
The above is possible but gets complex and I think it will cause issues. With hundreds of users it will be a nightmare to debug if something goes wrong.
Proposal 2:
Similar to our present method, but network verification to be done by checking if the network directory exists (fast), and logging to be done by starting a logging task that JMP does not need to wait for. I'm not sure if this is possible. Can JMP kick of a task to go write to a file remotely but not wait for it to complete? That would simplify this problem quite a bit.
Please let me know if you have any alternative ideas on this topic.
Thanks
Mike
