Franz wrote:
> Coming from Toolbook I had to realize and accept that ...
>
> runrev password protection protects stacks against
> * copiing objects FROM it
> * editing passwords
>
> It does not protect the stack against
> * copying objects INTO it (including scripts in this objects)
> * deleting objects within it,
> * moving around
> * reading/writing custom properties of stacks or objects etc.
>
> This causes the behavior that you can copy an object (even a
> background coming in front of the event hierarchy) INTO a
> password protected stack - but you cannot copy a modified
> object back then without putting the passkey ...
Yes, Rev's script protection does not attempt to hinder any form of
alteration of the message path, it merely prevents scripts from being
read. If you could copy an object from a protected stack to an
unprotected one, its scripts would become exposed.
There is a request to support password-protection of any object, not
just stacks:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=659>
(Note to RunRev: I am not soliciting votes here, just noting an existing
report that is relevant to the conversation. Whether or not someone
decides to add their votes for it is entirely at their own discretion.
The readers here are not my zombie legion. <g>)
> Because I have to copy the objects from my working stack to the
> tempStack first I have to use stacks without runrev password
> protection (to copy objects FROM) for my concept of persistent
> objects.
If you're copying objects, you may find it both more secure and more
convenient to maintain to have as few handlers as possible in those
objects, which merely call handlers in a central library or your app's
mainstack to do the real work, e.g:
-- In copied object:
on mouseDown
DoSpecialMouseDownThang
end mouseDown
-- In some central location:
on DoSpecialMouseDownThang
-- all the cool stuff your object does
-- goes here
end DoSpecialMouseDownThang
Not only does this provide complete protection for your proprietary
algorithms, but it also makes the code lighter in the copied objects,
minimally reducing memory usage. But more useful is that it keeps the
complex stuff in one place, so it can be maintained and enhanced without
needing to make sure that all copies of the script are kept in synch.
Just curious: What options does Toolbook provide for script protection?
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
