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!
