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 <ml...@carbinestudios.com> 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:* softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] *On Behalf Of *Martin > *Sent:* Tuesday, July 09, 2013 3:22 AM > *To:* softimage@listproc.autodesk.com > *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**** >
