This all sounds like an overkill. If you didn't want users / developers to
do this, why would you want them to have access to the said server? I'm sure
there is more to this, no?
Furthermore, it would had overhead to the interface. Patching or
intercepting calls to the UniRPC or servers it
Sounds like a pretty stupid idea to me.
Shut down unirpc and write something else instead.
Best option - buy redback and restrict access to the RBO designer. Then they
can only use the objects and their properties published.
Brian
-Original Message-
From: [EMAIL PROTECTED]
I use UOJ Not sure if the same approach can be done with Uniobjects.
But an idea that jumps to mind is to provide your developers with a suite of
classes other than the Uniobjects. In other words, put an abstract layer
around uniobjects that provides just the functionality you are going to
[snip]
A customer has asked how he could implement some stringent security on the
'unirpc' services. In particular, he wants to only allow certain 'Requests'
(like the 'Subroutine' method, etc.) from any users out there writing
UniVerse Objects front-ends.
[snip]
Overall, I think, like the
Hi Michael
The only thing I can think of is to restrict Access to Universe for this
account, so that they cannot write, update or delete for this user
group.
Create Subroutines that have this access writes to write Delete by
using the Authorization statement in the code, which allows you to
