2

In my system, I need my clients to be able to get a List of objects, representative of the service states/context. Say you have the following action done by a given client to retrieve the context:

List<someObjects> aList = GetListOfObjects();

Now the client is able to retrieve aList, but it can also modify this list before sending it back through the channel, which I would like to prevent (as it would not be representative of the system anymore). Therefore, the client should not be able to do:

aList.RemoveAt(1);          // Should not be possible to remove object from this list
SetListOfObjects(aList);

I thought I could create a readonly "aList" class, but I still want to be able to modify the objects' properties, so I don't thing it is the right thing to do.

One idea is to actually create a class, where all objects from the aList would be properties instead. That way, the class would impose a structure that could not be modified by the client. However, the system's context may vary (depending on the hardware being used), meaning this class would need to be dynamically created.
I however do not want to lose the type safety and hence would rather not use the dynamic or expando Objects.
Maybe using something of the sort is a good idea here, see answer from danijels. But I am not sure the type safety would be preserved by doing so.

stackMeUp
  • 522
  • 4
  • 16
  • 1
    ultimately, in a WCF scenario you have to assume that *you don't control the client*, unless they're going through an API library that you are providing. If you are: just rewrap the data on the way out, perhaps as an immutable array / collection? If you aren't (providing an API library for the client): it *isn't up to you*. In either event, you should *always* assume that the client is hostile and compromised. – Marc Gravell Apr 15 '20 at 09:33
  • Thanks @MarcGravell, that is an interesting approach, but makes sense to assume the client is always potentially compromised. I'll keep that in mind! I do control the API though. The entire system is ours, so no third party involved here. – stackMeUp Apr 15 '20 at 09:37
  • then... wrap it? – Marc Gravell Apr 15 '20 at 09:58
  • @MarcGravell. Is it not costly to make the list immutable though? – stackMeUp Apr 15 '20 at 10:09
  • Ant that won't prevent the client to modify the composition of the list, right? Will the client not still be able to do aList.RemoveAt(1), even if immutable? Maybe that is why you mentioned adding a wrapper. To verify the list is composed of the correct element? Is that what you meant @MarcGravell ? – stackMeUp Apr 15 '20 at 10:15
  • there are a myriad ways you could wrap it to prevent mutation; the *inbuilt* immutable types suffer from the fact that a caller can still use the mutate API and give you back the altered clone - but you could create your own collection type that *doesn't* support any mutate features – Marc Gravell Apr 15 '20 at 10:49
  • Thanks @MarcGravell, I will try to come up with something. – stackMeUp Apr 15 '20 at 11:14

0 Answers0