(inline) From: "Yuval Gross" <[EMAIL PROTECTED]> > i have the following design/implementation problem in c# / remoting: > > there's a document class (marshal by val), which is handed over from the > server to the client. > > the client should be able to update the document, only if it's not in > a 'read-only' mode (suppose the mode is accessible to the client via a read- > only property). to ensure that, all property 'setters' first check for the > mode, and throw exceptions if the mode is 'read-only'. > > only the server should be able to create a writable doc.
What's supposed to happen to the document after the client modifies it? How about the factory pattern? The client has one factory type that only creates readonly documents and the server has another that can create either kind of document. This wont be temper proof either. If the client has the code he can do whatever he wants with it. If you want to protect against that you will have to check the document on the server. > > so far this is a regular design problem, only in c++ i could have solved it > by declaring the server class as a friend of the doc (not a perfect > solution, but would do the trick). not possible here... The client could always hack the x86 code. > i tried creating a derived class 'entityDoc' that has a setter to the state > (which is now public), and passing the client that object. > the problem is the remoting mechanism serializes all the deatils of that > class, including the fact it's a serverDoc, and on the other side it tries > to create the instance via reflection, but the client doesn't have a > reference to the serverDoc manifest, so it fails... > > another (not so good) possible solution is to use events: the doc wil be > handed an IDocModifier object which will have several events for updating > the doc's properties, the doc will register on to the events and when those > are raised, it will change the properties. the problem here is that since > the doc's manifest 'knows' the IDocModifier, so will the client, so it will > be able to create a modifier object and modify the doc itself. > > another (a real stinker this one) solution is to somehow use the .NET > security mechanism to allow only the server process to call the doc's > modifying methods. > > any ideas...? > Unless the document has to be sent back to the server there's no way to prevent the client doing whatever he wants to do if he really wants to do it. Ok, you could always include a really big and scary guy with each software packet. :) Peter You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
