Securing dynamo scripts

Civil3D
,
1

Hi,
I am creating some dynamo scripts for my work and my team. I feel like i want more security over my scripts. I want the scripts to be used by me and my team only, basically to be used on some specific machines only. Is there something in dynamo which can help me secure my scripts?
I’ll give more details: basically, I want that the script should run only on machines specified by me. other than those, the script would crash or not support.
Please let me know if any of you know about such thing.

2

More of an IT question this, but yes it it possible to create a network mapping to a directory only certain people can see or access.

3

Dynamo isn’t the right platform if you want that type of restriction. Build an add-in instead.

2 Likes
4

If you want a hacky solution you could build a python node to check username or something and pass fail on that but it wouldnt stop anyone simply removing the node.

1 Like
5

I believe you can use this instead.

My own method is just using pyRevit and turning most scripts into a toolbar. It will lose all Dynamo Player functions though, so if you use Data Shape nodes as your inputs, then you still can’t retain previous inputs like Dynamo Player can (as far as I know)

1 Like
6

Agree on that. User will still have access to the graph.

7

As far as I am aware that is the same with Orkestra - if a user wants it they’ll be able to get to it.

For actually securing graphs you either need to get VERY creative with zero touch nodes or other tools which execute compiled code (C#) rather than scripts (Python, Design Script).

8

But why?

2 Likes
9

It is the way Dynamo was written from the outset. It is effectively open source and written using compiled code, versus being compiled itself. This enables the concept of visual programming to work in essence and is why other platforms of this nature tend not to offer protection.

Like Jacob said, if your goal is to lock down your tools you should be aiming for C# in your learning journey. This will let you compile your code which effectively prevents the source being read normally.

The main reason beyond this to me is locking up Dynamo scripts is really not in the spirit of Dynamo itself. Look at any thread here where someone asks for help, then refuses to share their script or a simple sample model- tends to go down badly. Why would a community feel incentivized to put time into one way exchanges of ideas and information. Dynamo is very much about sharing - ideas, code and ultimately growth together as an industry.

5 Likes
10

I understand the spirit behind sharing but it’s just that there are some specific scripts written for specific projects. So, it’s not about hiding things, it’s about protecting it so that it can’t be used without permission. It’s more of an IP thing.

11

can you please elaborate on it.

12

is there any option to build some extensions in dynamo through which i can achieve this?

13

The ‘security’ here is in setting up the directory which contains the scripts to be a location with specific permissions. This means that only specific users can see the graphs at the outset - the files are there for that one team and no one else. However anyone in that team can be open any graph and then save it elsewhere, or even just copy and paste it to another location without issue. And that ‘elsewhere’ will likely not have the same permissions and thereby the security is minimal. So it is entirely as secure as your trust in the individuals which you allow to access the graphs.

Hard to talk around this without seeing the IP in question, but what sort of IP is of concern here?

  • If only standard nodes the content isn’t really IP worth protecting - likely all of the people who have replied in this thread can reproduce the graph with nominal effort proportional to the size of the routine - and for really big lifts many would optimize it by moving past Dynamo as well. The real value in the IP is knowing that it is a thing you did, and anyone who knows the dyn exists already has that insight so the IP protection is moot.
  • If there are custom nodes or scripts written in Python or Design Script that do not leverage any classes beyond the standard Dynamo and Revit API imports it isn’t really IP worth protecting as most of the people who have replied to this thread can reproduce the result with as much of not less effort than managing the inherited codebase. Basically if ChatGPT can reproduce 75% of your script you have the value of the IP protection is moot.
  • If there are scripts written in Python or Design Script that utilize custom classes or objects not found in standard imports it’s likely valid IP which you should secure by moving to compiler solution (zero touch nodes). These will be faster (on average 1/20 the execution time to optimized Python in my testing) and you can ensure they are only used by authorized individuals meaning that even if the DLL winds up in a public facing package it will not execute.

This is what I was getting at before; the answer is ‘yes, you can leverage a view extension in Dynamo to limit execution, but it is a LOT of work (10-20 days of a full time developer, depending on their skill level), and falls into the ‘if you have to ask you aren’t ready to build this’ category. The general steps are as follows:

  1. Configure your own authentication server. Ideally you would use a service for this (i.e. Azure AD), but you could home brew it as well. Remember that users who cannot see this server will not be able to authenticate, and users without a valid username and password with not be able to authenticate. If you home brew a server keep in mind basic cryptographic concepts and local laws and regulations around storing user data as you set it up. Also maintaining that home brewed server could become a full time job in and of itself and is separate from Dynamo.
  2. Build a Dynamo view extension to issue a token from your authentication server. Set the timeout as desired.
  3. Build your custom nodes as zero touch nodes. Have each node start by checking for an authentication token. If present and valid proceed. If not present trigger the authentication view extension, and use the returned token. If unable to authenticate inside a given window (5 minutes), throw a warning and pass null).

Now this may seem a step beyond the previous ‘use a zero touch node’ advice, but it enables active management of the users via the authentication token, while the previous example could only use something like the current username or another basic windows feature - once you enable via that protocol the tools can migrate between projects and locations without any ‘off switch’ which you can pull.

3 Likes
14

Thank you for the detailed explanation @jacob.small. I will think on all these ideas and try to see which one works best for me.