As of trunk r435, this is fixed for DevTeam and Game (which were needed
for other bugs).
Remaining services: Achievement, GameFile, GameVersion, KeyValuePair.
--
You received this bug notification because you are a member of MUGLE
Developers, which is a direct subscriber.
If you look at UserServiceImpl, that is implemented correctly (I assume
this one was implemented first, and the others were copied). All of the
ServiceImpls are using logic that compares the current user's key to the
object's key, which is nonsense (completely different types), EXCEPT for
when
I am trying to get my head around the purpose of checkPermissions. The
canonical version, in UserServiceImpl, seems to do the same thing twice,
and the second check is rather redundant. The cloned versions have been
modified to do the first check properly, but not the others.
Here is pseudocode
I am wondering what happens if I simply remove that early check
that throws the UserPrivilegeException, whether the privileges
are still taken care of later on.
It seems that if you remove the early check, no exception is thrown; the
data just silently fails to be written. From a client
So bug #786904 is the inverse of this one. Not only do we get private
when we should get public, we also get public when we should get
private, so nobody other than admins will be able to write.
--
You received this bug notification because you are a member of MUGLE
Developers, which is a direct
5 matches
Mail list logo
