Add Serializable classes of model to be passed by GWT RPC

[Scott Ritchie]

Write serializable versions of each of the model classes to be passed over by GWT RPC so they can be accessed by the client side of the platform; Should only have getters (and setters ?), and should only contain information the client side should be able to see (so there'll need to be 2 versions of some of the model classes according to the public/private nature denoted in the Platform View)

[Prageeth Silva (prageethsilva)]

I've already started implementing these classes as part of the datastore wrapper.
This includes Services too. However, it may take a couple of days to get everything completely implemented and I'd commit all of it as soon as I'm done.

[Matt Giuca (mgiuca)]

I'm still a bit concerned about this approach. I talked to Prageeth about it yesterday.

Firstly, I am concerned that these "info" classes will duplicate a lot of code. You will need to specify all of the fields again in the info class as you do in the model classes, and if you need to change any fields, update both versions. As you outline in the bug description, you might need two versions of each class as well -- that implies a lot of duplication. Please try to avoid this if possible! Prageeth suggested using null to hide the data rather than a separate class.

My second concern is that there would be a security issue if any data was placed in an info class that shouldn't be accessed by the person that is receiving that class, even if the client code doesn't make it available. It doesn't seem tractable to manually write different versions of each class for different stakeholders -- e.g., a dev team may need to be visible to admins, lecturers, the team themselves, and other non-team members. That's four different access groups who may have four distinct sets of fields they can see. Any mistakes would be security vulnerabilities. A general solution might be required, where on the server side, the access level is used to construct the correct set of fields to put into the info class.

[Prageeth Silva (prageethsilva)]

I think I have taken care of most of the issues Matt is concerned about.

So here's a summary for my plan. First of all, i agree with the fact that there will be an exact copy of fields in both the model class and the info class. This means that when a new field is added or removed in the model class, it needs to be done in the info class as well.

About having different versions of classes; I was thinking of using null as Matt mentioned earlier. And this will all be done on the server side (by looking at the current login). I've already added the static methods that take in a model class instance and the role of the current logged in user; and it returns the the counterpart (info instance) with the desired fields been set to null. However, I have not completely implemented this yet. So I personally don't see a security issue since only the desired values are passed back to the client.

I hope this implementation would be better.

[Matt Giuca (mgiuca)]

> I personally don't see a security issue since only the desired values are passed back to the client.
Right. If only the desired values are passed back to the client, then there is no security *vulnerability*.

I say security "issue" since I would be concerned that if any one mistake was made in selecting which fields to set to null, then we would be leaking information to the client. In other words, it seems a bit too flimsy.

The main concern is just that the code for doing this will have to be written specially for each field of each class. I would feel better about it if there was some generic code which handles all the logic for selecting which fields to null out. Is there?

[Prageeth Silva (prageethsilva)]

Yes you were correct in saying that we would have to do it for every field manually. I can't seem to think of a way to get this done in a generic manner.

As I was suggesting yesterday, given the use of annotations work, this could still mean that we have to manually select which fields need to be hidden or not. This also takes us back to the same problem; any mistake in the selection could result in the same issue you mentioned above.

Anyhow, should I go ahead and implement what I already planned? Or should I wait till the decision is finalized?

[Prageeth Silva (prageethsilva)]

I was looking at creating custom annotations, that might come in handy to create this generic form.
The link below gives examples of how this can be used:

http://download.oracle.com/javase/1.5.0/docs/guide/language/annotations.html

I would think that we should have an annotation called the @UserLevel that takes in the Role enum (annotations are allowed to only have primitives, String, Class, enum and array of those types).

So depending on which Role it is, going from User -> Developer -> Admin, the info classes can be generated on the run, without us manually having to do this for every field.

If this seems to be a better approach, please let me know so that I can start implementing this.

[Matt Giuca (mgiuca)]

This should be marked fixed when Prageeth merges his data-wrapper branch.

[Prageeth Silva (prageethsilva)]

The branch has been merged with the trunk and everything compiles but GWT complains about java.io imports in shared or client packages. I've addressed that in https://bugs.launchpad.net/mugle/+bug/728148 and I'll look into this.