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 allow.
Now, the only way you can prevent developers from utilizing the actual uniobjects is to perform some kind of code review, since anyone can get their hands on them. -----Original Message----- From: Michael McRae [mailto:[EMAIL PROTECTED] Sent: Friday, March 26, 2004 1:30 AM To: [EMAIL PROTECTED] Subject: Writing a "RPC Service" 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. To me, this means he wants unirpc to fire off uvserver when requested by UniObjects, but to have uvserver only forward on his allowed Methods (and no other). This would keep developers from writing code that could .Read, .Write, .Delete, etc, and force them to obey his security standards. 1) The first option I can think is to 'intercept' the uvserver executable. Has anyone any experience with writing their own Services for unirpc? 2) Next, how about distributing a cut-down version of the DLL (or is it OCX?) that his users will bind into their app? Hoping there's a chance... Michael McRae -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
