Restrict Scripts

Ignition
1

Hello,

It is possible to resctrict scripting in a project?

2

What exactly are you trying to accomplish?

3

I’m trying to hide my scripts from other users

4

Well, in this case there are two things you can do:

  1. Make your own functions using the module SDK such as an expression or scripting function to hide the code.

  2. You can lock the project so they can’t edit it in the designer.

5

how do you carry out the number 2 option?

6

Is there a python function to execute code contained in a variable? If so, you could store your code in your SQL database, then use the security in the RDBMS system.

7 
eval("print (7+9)")

Storing code in the SQL database sounds like disaster waiting to happen…

8

Sounds like stored procedures to me :slight_smile:

9

I'm not sure one way or another. You are adding a layer to troubleshooting and possibly providing a vector for things like SQL injection attacks.

I haven't tried or really thought about that. Treat is as "another wild idea" :slight_smile:.

10

I don’t think code run through eval() would have access to the surrounding context, i.e., events, components, etc… Aside from it being just not a good idea. There’s also performance implications.

11

How about an answer for #2 from Travis? Would this just be implementing the security policy role to
allow or not allow access to the designer/project.
How does this work down to the project level when two separate users have access to designer?

12

I would suggest making a role that only the person(s) who is designing the project has a username and password for. Restrict your access by only assigning certain people access.

13

I think this gets into the more general issues of: more flexible role based security and natively supporting multiple authors and projects.

The first idea extends control over roles, functions, and objects (ie, a group/person that can edit some scripts/windows/tags/users, but not others). The idea has been kicked around for a more flexible security model. There are a number of builtin or architectural means that could support such requirements. I tend to first favor simplicity, then programmatic flexibility.

In the past we’ve kicked around the idea of a “hosted” version where an Integrator could have a number of customers who each have admin level access to their own project, but not each other’s. This could be seamless, like how the large web hosting sites do it for concurrent customers. I would expect this to naturally cover different levels of admins for a single project.

Again, my $.02 looking into future features.

14

Thanks for all your answers. I will try using JDK :thumb_right: