Re: [Mugle-dev] Policy decision: Full names
That sounds good, i think we had initially set it to private for privacy reasons. On Wed, May 25, 2011 at 8:44 PM, Matt Giuca matt.gi...@gmail.com wrote: Hi, I was under the impression that we would show users full names publicly. However, that doesn't seem to be the case; the public view has only admins able to read the full name. This causes the user view to fall back to displaying the user name. I think it's better if we show users full names. This is a professional site and we should be able to see the authors of the games, and students can also use it as a resume so it will need to show their names. I recommend changing it so guests can read users' fullnames. Does anybody disagree? Matt -- 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 -- 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
[Mugle-dev] Active version gets cleared
I am really confused about this.
https://bugs.launchpad.net/mugle/+bug/788075
Is there some weird bug going on in the bowels of the database layer? I
doubt I could have screwed up on the UI, and that's all the code I changed.
In GameEditBuilder, I added:
game.setIsPublic(publicBox.getValue());
// Attempt to submit changes to server.
game.write(new AsyncCallbackGame() {
});
That's it. Now when I do that, the ActiveVersion field is getting set to
null. Can someone please help? This is quite critical, because it corrupts
every game you edit.
--
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
Re: [Mugle-dev] Active version gets cleared
Never mind, I figured it out and worked around it (hackily). https://bugs.launchpad.net/mugle/+bug/788075 -- 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
Re: [Mugle-dev] Active version gets cleared
OK, let me know if you want me to check on it. I'll be online for a while. -- *Prageeth Silva* -- 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
Re: [Mugle-dev] Active version gets cleared
Just got home a little while ago. OK I'll check on this since it's
critical.
On Wed, May 25, 2011 at 9:57 PM, Matt Giuca matt.gi...@gmail.com wrote:
I am really confused about this.
https://bugs.launchpad.net/mugle/+bug/788075
Is there some weird bug going on in the bowels of the database layer? I
doubt I could have screwed up on the UI, and that's all the code I changed.
In GameEditBuilder, I added:
game.setIsPublic(publicBox.getValue());
// Attempt to submit changes to server.
game.write(new AsyncCallbackGame() {
});
That's it. Now when I do that, the ActiveVersion field is getting set to
null. Can someone please help? This is quite critical, because it corrupts
every game you edit.
--
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
--
*Prageeth Silva*
--
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
Re: [Mugle-dev] Active version gets cleared
No but ... never mind. It's no longer critical. -- 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
[Mugle-dev] [Bug 788083] Re: Anyone can request private games for a given devteam
** Description changed: Currently, the DevTeamService.getGames has a boolean to ask for public or private. This is necessary because the dev team edit page contains the full list. Note that since we have no security on viewing things at - all (pretty much), there is no point fixing this until then. + all (pretty much -- see bug #786876), there is no point fixing this + until then. -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/788083 Title: Anyone can request private games for a given devteam Status in Melbourne University Game-based Learning Environment: Triaged Bug description: Currently, the DevTeamService.getGames has a boolean to ask for public or private. This is necessary because the dev team edit page contains the full list. Note that since we have no security on viewing things at all (pretty much -- see bug #786876), there is no point fixing this until then. -- 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
Re: [Mugle-dev] [Bug 788083] Re: Anyone can request private games for a given devteam
I think implementing the security properly would solve a lot of the bugs we currently have. I just wish i had the time to sit down for a few hours and do it. On Wed, May 25, 2011 at 11:11 PM, Matt Giuca 788...@bugs.launchpad.netwrote: ** Description changed: Currently, the DevTeamService.getGames has a boolean to ask for public or private. This is necessary because the dev team edit page contains the full list. Note that since we have no security on viewing things at - all (pretty much), there is no point fixing this until then. + all (pretty much -- see bug #786876), there is no point fixing this + until then. -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/788083 Title: Anyone can request private games for a given devteam Status in Melbourne University Game-based Learning Environment: Triaged Bug description: Currently, the DevTeamService.getGames has a boolean to ask for public or private. This is necessary because the dev team edit page contains the full list. Note that since we have no security on viewing things at all (pretty much -- see bug #786876), there is no point fixing this until then. -- 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 -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/788083 Title: Anyone can request private games for a given devteam Status in Melbourne University Game-based Learning Environment: Triaged Bug description: Currently, the DevTeamService.getGames has a boolean to ask for public or private. This is necessary because the dev team edit page contains the full list. Note that since we have no security on viewing things at all (pretty much -- see bug #786876), there is no point fixing this until then. -- 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
[Mugle-dev] [Bug 779015] Re: Client can write back modified primary key
Is this actually a problem? I think the fact that the client has access to the primary key is the wrong thing to focus on. Obviously the client can write back anything they want -- if there is a security problem, it's that the server will let clients write to objects (based on primary key) that the client does not have access to. Now surely, the permissions system prevents that? So it seems like this is a non-issue. ** Summary changed: - Wrapper class containing PrimaryKey + Client can write back modified primary key -- 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: 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? -- 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
[Mugle-dev] [Bug 786016] Re: Direct Access to Services from client side
Can someone figure out if this is still an issue? I don't want old bugs lying around if they are not real concerns. -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/786016 Title: Direct Access to Services from client side Status in Melbourne University Game-based Learning Environment: Triaged Bug description: While Prageeth has coded the casting of shared objects to datastore objects to have security checks, these can be bypassed by calling the shared services directly. The type of these classes should be changed to Protected if possible to avoid this -- 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
Re: [Mugle-dev] [Bug 786016] Re: Direct Access to Services from client side
I dont think, this is a non-issue, once security is implemented properly. On Wed, May 25, 2011 at 11:32 PM, Matt Giuca 786...@bugs.launchpad.netwrote: Can someone figure out if this is still an issue? I don't want old bugs lying around if they are not real concerns. -- You received this bug notification because you are a direct subscriber of the bug. https://bugs.launchpad.net/bugs/786016 Title: Direct Access to Services from client side Status in Melbourne University Game-based Learning Environment: Triaged Bug description: While Prageeth has coded the casting of shared objects to datastore objects to have security checks, these can be bypassed by calling the shared services directly. The type of these classes should be changed to Protected if possible to avoid this To unsubscribe from this bug, go to: https://bugs.launchpad.net/mugle/+bug/786016/+subscribe -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/786016 Title: Direct Access to Services from client side Status in Melbourne University Game-based Learning Environment: Triaged Bug description: While Prageeth has coded the casting of shared objects to datastore objects to have security checks, these can be bypassed by calling the shared services directly. The type of these classes should be changed to Protected if possible to avoid this -- 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
[Mugle-dev] [Bug 779015] Re: Client can write back modified primary key
Yes this is no longer valid as long as our permission system works properly. -- 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: 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? -- 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
[Mugle-dev] [Bug 779015] Re: Client can write back modified primary key
** 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
[Mugle-dev] [Bug 786876] Re: Almost all data access is given private privileges
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. https://bugs.launchpad.net/bugs/786876 Title: Almost all data access is given private privileges Status in Melbourne University Game-based Learning Environment: Triaged Bug description: The data view system has been horribly abused. I haven't made a complete analysis of all the classes, but by the look of it, in most cases, objects are being presented with the private view whether the user owns it or not. Particularly the Game, GameVersion and GameFile exhibit this. The offending code is in the ServiceImpl classes, which assign the view type. At this point, most of our security is happening by accident, and can easily be subverted. It looks like most of the WRITES have buggy checks which end up resulting in private no matter what (eg, make it public if two keys of incompatible types are equal, but otherwise make it private). Most of the READS simply assign private without any checks at all. This code needs a complete audit. Note that you often don't notice these problems, because the role isn't high enough even for private access. For example, on GameData, most fields have public access for admin only, but private access for developers. That means guests can't see Games, but developers have full access to games - even ones they didn't create. This demonstrates the silliness of the developer role (bug #786842). This bug is responsible for bug #786685. -- 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
[Mugle-dev] MUGLE 0.1 release
Well, that's it. I've ticked off every single bug that we had milestoned. MUGLE is now pretty darn usable, and somewhat secure :) A user should now be able to (once given a dev team), navigate around all of the necessary UI to view and edit (where authorized) all of the games, teams and users. All fields that should be editable are editable, and users should be able to upload and serve games (though I am worried that some of the games will be too big -- each file must be under 1MB and the whole zip must be under 10MB). I am now prepared to make the release 0.1, upload it onto app engine, and then invite a handful of students onto the platform. If anybody has any reason why this product should not be uploaded to this platform in holy HTTP transfer, speak now or forever hold your peace. Note: I am also about to change every single Fix Committed bug to Fix Released -- please hold onto your inbox. Things may get a little rough (if you are subscribed to bug mail, you will receive 78 new emails; you can just delete them immediately). -- 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
Re: [Mugle-dev] MUGLE 0.1 release
The list of bugs fixed is here: https://launchpad.net/mugle/+milestone/0.1 -- 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
Re: [Mugle-dev] MUGLE 0.1 release
Nice :) I am curious how it looks like now. On Thu, May 26, 2011 at 11:23 AM, Matt Giuca matt.gi...@gmail.com wrote: The list of bugs fixed is here: https://launchpad.net/mugle/+milestone/0.1 -- 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 -- 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
[Mugle-dev] [Bug 788425] [NEW] User can change URLname to that of another user
*** This bug is a security vulnerability *** Private security bug reported: It is possible for two users to have the same URLname. Check this and block it. ** Affects: mugle Importance: Critical Assignee: Matt Giuca (mgiuca) Status: In Progress ** Tags: datastore ** Changed in: mugle Milestone: None = 0.1 -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/788425 Title: User can change URLname to that of another user Status in Melbourne University Game-based Learning Environment: In Progress Bug description: It is possible for two users to have the same URLname. Check this and block it. -- 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
[Mugle-dev] [Bug 788425] Re: User can change URLname to that of another user
** Branch linked: lp:mugle -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/788425 Title: User can change URLname to that of another user Status in Melbourne University Game-based Learning Environment: Fix Committed Bug description: It is possible for two users to have the same URLname. Check this and block it. -- 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
[Mugle-dev] [Bug 788425] Re: User can change URLname to that of another user
Fixed in trunk r451. ** Changed in: mugle Status: In Progress = Fix Committed -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/788425 Title: User can change URLname to that of another user Status in Melbourne University Game-based Learning Environment: Fix Committed Bug description: It is possible for two users to have the same URLname. Check this and block it. -- 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
[Mugle-dev] [Bug 788425] Re: User can change URLname to that of another user
** Changed in: mugle Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/788425 Title: User can change URLname to that of another user Status in Melbourne University Game-based Learning Environment: Fix Released Bug description: It is possible for two users to have the same URLname. Check this and block it. -- 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
[Mugle-dev] [Bug 786685] Re: GameToken is visible to users who don't own the game
** Changed in: mugle Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/786685 Title: GameToken is visible to users who don't own the game Status in Melbourne University Game-based Learning Environment: Fix Released Bug description: The permissions system stops you from writing anywhere you shouldn't, but there don't appear to be any restrictions on what you can view. Any user can go around to #!/devteam/game/+edit and see everything there, including all the badges, and the game token. Users need to be restricted from accessing certain kinds of data. Note that this can't be done on the client side. The server needs to refuse to give you certain objects (or refuse to fill in certain fields) if you ask for them. -- 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
[Mugle-dev] [Bug 786594] Re: Upload service does not check permissions
** Changed in: mugle Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of MUGLE Developers, which is a direct subscriber. https://bugs.launchpad.net/bugs/786594 Title: Upload service does not check permissions Status in Melbourne University Game-based Learning Environment: Fix Released Bug description: A pretty glaring security bug that I don't have the time or expertise to fix at this stage. Currently, anybody can upload a file over the top of anybody else's game. This is fairly critical (I need to learn how to check permissions, or someone else needs to do it). -- 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
Re: [Mugle-dev] MUGLE 0.1 release
OK, it is released. http://mugle-app.appspot.com/ I have added everyone on this list to the Staff team, so you can upload games if you wish. Any game you upload will be private by default, so feel free to do so (but don't check public for now; we just want the student's games to appear in the list, though possibly we can make the electric circuits game public). Also, you should change your usernames to whatever you want; they default to your Gmail username. And set your real name too. -- 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
