In that case I would recommend you prevent contamination and destruction at a filer level through permissions tied to groups, and try to convince the owner the effort of protecting trivialities added to the missed productivity of not offering them to the users usually far out-costs the damage of having simple scripts stolen.
It'd be a different deal if security was involved, IE: scripts and hacks that if seen in plain text could compromise access or data (horrible things such as plain text passwords), but unless you have some truly novel algorithmic worth prototyped in plain text somewhere in a python file, usually scripts contain a topmost layer that is irrelevant without the infrastructure, or perform tasks that if someone stole such productivity boosters would hardly lose you clients to the thief. As I said, for Python you can move a fair chunk of stuff to pyc only and introduce a thin (but for most non tech savy users already impregnable) barrier. If someone steals something written in VBS I have it on good ground they usually die of some horrible skin disease within the year anyway, so that takes care of itself. JS you will just have to live with it having been stolen. You got anything critical written in JS? On Wed, Jul 10, 2013 at 3:14 PM, Martin <[email protected]> wrote: > We are a small company, and we have some tools that aren't really that > great, but the company's owner is asking me if we could do something to > protect them. For me they are simple code, but for him they are property of > the company. > > I understand him but I don't think protecting all of our simple scripts > would worth the trouble, so I may end up convincing him to just give up or > hire a specialist. > > In my previous work, the chief programmer used to protect all the compiled > tools with some sort of intranet authentication so the tools could only be > used when the PC is connected to the company's LAN. I didn't want to do > that because I would have to rewrite every vbs and js files to something > compilable, so I was wondering if it could be done at file management level. > > Me, I just want to protect the files to avoid pollution. One time I had a > designer complaining that some script I wrote wasn't working, and when I > opened the script file, it was blank. It seems that he opened the file in > the script editor, who knows why deleted everything and when he was closing > SI just clicked on save. > > Martin > > > On Wed, Jul 10, 2013 at 1:44 PM, Raffaele Fragapane < > [email protected]> wrote: > >> Can I ask on what grounds? >> It's very hard to think of something you could write in Python (let alone >> in JS or VBS) that, without the company's infrastructure, would represent >> enough of an edge to be protected so fiercely. >> Unless it's a security risk, and not the "theft" of the tools worrying >> somebody. >> >> I've seen it fairly frequently where some places got fairly protective >> about some stuff that without the asset/infrastructure was downright >> useless, or that was held in high regard but really was so incredibly >> trivial that the round-about ways taken to protect it got quite laughable. >> >> You can always offer only the pyc compiles for most of the stuff anyway, >> so all they would get is bytecode. Reversible, admittedly, but again, is it >> really such hot property that it's worth protecting? >> >> >> On Wed, Jul 10, 2013 at 2:25 PM, Martin <[email protected]> wrote: >> >>> My main goal was to share a Workgroup folder for main production, and we >>> have some not compiled (jscript, python, vbs) plugins that we don't want to >>> be copied, specially if we are going to have outsource temporal workers >>> helping us. I'll have to look for another solution. Code protection sounds >>> like a very troublesome task. >>> >>> Matt's suggestion sounds interesting, I'll give it a shot. Thanks. >>> >>> Thanks again, >>> >>> Martin >>> >>> >>> On Wed, Jul 10, 2013 at 9:01 AM, Matt Lind <[email protected]>wrote: >>> >>>> Depends on your goals/needs:**** >>>> >>>> ** ** >>>> >>>> If you’re trying to set up a renderfarm and have a workgroup set up to >>>> be used by the nodes, then just put the workgroup on a machine where users >>>> cannot reach it.**** >>>> >>>> ** ** >>>> >>>> If you’re trying to set up a workgroup to be used by users in main >>>> production, then you really can’t hide the workgroup as Softimage operates >>>> under the same user permissions as the user. The best you can do is make >>>> the workgroup read-only.**** >>>> >>>> ** ** >>>> >>>> One thing you could try is an old-school method that was employed >>>> before the existence of workgroups - write your tools as script functions >>>> in files instead of self installing plugins. The concept is to write a >>>> master wrapper command that acts as a front end to call all the other >>>> commands using Application.ExecuteCommand() or Application.ExecuteScript() >>>> or Application.ExecuteScriptCode(). The scripts can be placed on any >>>> server away from user direct access, or can even be embedded in a database >>>> table which is called dynamically. There will be a slight hiccup while >>>> the plugin looks for the command to execute in the database table, but it >>>> completely hides the location of the script preventing user tampering >>>> unless they’re quite adept at scripting to extract whatever it is you’re >>>> protecting.**** >>>> >>>> ** ** >>>> >>>> The technique I use is to brute force replace the contents of the >>>> workgroup on application startup. I intended this to be a way to ensure >>>> users all have the latest versions of the tools, but it has a beneficial >>>> side effect of frustrating users enough they don’t bother tampering with >>>> the workgroup because they know any modifications they make are only valid >>>> as long as the current session. Next restart and all their changes are >>>> wiped.**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> Matt**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> *From:* [email protected] [mailto: >>>> [email protected]] *On Behalf Of *Martin >>>> *Sent:* Tuesday, July 09, 2013 3:22 AM >>>> *To:* [email protected] >>>> *Subject:* limit access to workgroup**** >>>> >>>> ** ** >>>> >>>> Hi list,**** >>>> >>>> ** ** >>>> >>>> This isn't exactly an SI question but I was wondering if there is any >>>> way to limit direct access to a SI Workgroup allocated in a server so it >>>> could be used by SI, but not copied or altered.**** >>>> >>>> ** ** >>>> >>>> Martin**** >>>> >>> >>> >> >> >> -- >> Our users will know fear and cower before our software! Ship it! Ship it >> and let them flee like the dogs they are! >> > > -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
