Save it

It may be that UserInfo is not available (which may occur even when a user is logged in). Try either saving the user name when you initially check for user login, or use 'isStorageAvailable' before using 'getUserName'.

Notice this little snippet of code: if (this.name.equals("SPower")) { Button butt = new Button(ADMIN_BUTTON); butt.setResponder(this); addObject(butt, getWidth() /2, getHeight() /2 +100); } that gives you the 'Admin Button' if your username is SPower. And this: public void banUser() { if (this.info != null) { this.info.setString(BANNING_INDEX, "" + System.currentTimeMillis()); this.info.store(); } }

Really, I don't think that's bad. Your password is hashed, so I can't access it (you can't un-hash something). And also, banning a user only happens when you enter the wrong password too many times. Ok with all that? And if I wanted to use it to my own advantage, why would I post the source?

I don't quite understand what you mean when you say it's hashed, unless Greenfoot does that automatically when you store data, because it seems like it's just storing the password as a regular string. Regardless, it's not like anyone is storing important data on this scenario (unless they were stupid enough to use their greenfoot account password for this password) and I was just pointing out that it seems you have total control. I didn't mean to offend you in any way. Also, are people allowed to use your 'Saver' and 'Scoreboard' classes if they cite credit? Greenfoot seems pretty open with people sharing code for reuse in different context, although you can get a project removed for plagiarism.

Well, hashing is essentially turning a lot of data into a small form, which is almost impossible to crack, because a small change results in a completely different hash (The code for to hash the passwords is in the Coder class). This means that you can only compare the hash of the entered password to the stored one, and check if they are the same: the same data always has the same hash. And I wasn't really offended :) And yes, of course you may use the classes! That's why I posted the source! And ScoreBoard is from the greenfoot team, not me. And if you want to know more about hashing, I saw a good video about it: https://www.youtube.com/watch?v=b4b8ktEV4Bg

Only the owner of the scenario has access to other users UserInfo data. This does not mean that the scenario cannot be programmed to share some or all information of one user with another. My 'Private Messaging' scenario will display the names and profile pics of any user that has used the app; however restricts the sharing of the data stored (the 'score' field, the ten 'int' fields, and the five 'String' fields) to just one String field; and then, only if certain conditions exist (that communication is intended between the two users). I am the only one who can access all communications between the users because I wrote and uploaded the scenario onto the site. All in all, as far as total control, I would say that, yes, the author (or uploader) of a scenario has total access to all UserInfo data and controls what information is shared between users. The only thing the author cannot do (well, not very easily), is change what information is stored in the UserInfo data of other users. An author can program the scenario to alter the data for a user when they run the scenario while logged onto the site. Even if data is encoded, I cannot see how the key would not be accessible to the author (it would either have to be a programmed constant or it would have to be stored somewhere within the UserInfo data).

Thanks SPower! And danpost, I was just pointing out that he had total control; I understand how it works.