** Changed in: mugle Status: Triaged => Invalid -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/779015
Title: Client can write back modified primary key Status in Melbourne University Game-based Learning Environment: Invalid Bug description: As discussed at the last meeting, the primary key is set in the wrapper class when casting from DataClass to ClientClass (wrapper class). This was mainly because we needed to send the key back via a service to do updates and similar operations. However, after brain storming about this more, I can see that this can have security issues. What if the client manually edit the primary key (basically a long) and that new primary key actually mapped to another user in the database. This means that the client would be able to change data of other users. One may say, we can simply check on the server whether this user is the actual user that's logged in. This would also mean that a user is limited to changing only his profile and this could be a problem for admins. I still can think of a work around by simply using the UserLevels (that was also my initial plan). But now if we consider any other model class other than the user; e.g. UGP will contain a list of games (game keys rather). And if the client wants to update a single game in the list by passing down the key of that particular game, we SHOULD allow that. But what stops the client from changing the UGP's list of games and performing the same operation? I can't think of a work around for this scenario, and I'm wondering if this will be an issue or not? -- Mailing list: https://launchpad.net/~mugle-dev Post to : mugle-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~mugle-dev More help : https://help.launchpad.net/ListHelp