mugle-dev team mailing list archive

[Matt Giuca <779015@xxxxxxxxxxxxxxxxxx>]

** Changed in: mugle
       Status: New => Triaged

-- 
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:
  Wrapper class containing PrimaryKey

Status in Melbourne University Game-based Learning Environment:
  Triaged

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?