The User ID system needs work

,
1

Most chat applications on the Game Lab directory use getUserId() to track bans, admins, usernames, collected themes/emojis, and coins. It works perfectly fine when it’s being used by a logged-in user. However, it doesn’t work the way it should with a logged-out user.

When you’re logged in, your user ID is stored on the server, and is retained in between sessions. When you’re logged out, your user ID is stored locally, and can be refreshed by clearing cookies.

Some users participate in good faith, and legitimately do not know that their user ID isn’t saved. This causes confusion when they lose their coins and items, and when they have to remake their account (with a different username, too, in most cases).

Other users abuse this system by repeatedly breaking rules, and making a new user ID simply by clearing cookies when they’re banned. I’m suffering from this issue right now, with one user repeatedly spamming in the #general channel in WUTCord, even though there’s a #spam channel for that exact purpose.

This issue isn’t exclusive to WUTCord. Basically every chat on the entire Game Lab page suffers from this issue. It’s almost trivial for the admins to fix this issue.

In the Applab and mostRecentGameLabInstance variables, there’s a key called user. That tracks two things: the user ID and if that user is logged in or not. It should be extremely easy for the admins to just have getUserId() return “(not logged in)” if the loggedIn variable is false. It would solve so many issues with both App Lab and Game Lab.

2

@wutadam,

Sorry for your frustrations. These kinds of observations and/or requests should be submitted to support@code.org so they get to the right eyes. The engineers rarely visit the forum and don’t usually see these kinds of requests so they are best addressed by emailing the support team.

Thanks!

Mike

3

Actually, the best way is to force everyone to make an account regardless. This will prevent any misuse of the program. You can even create a variable such that if loggedIn != true, then they stay on the register/login screens.

4

I definitely agree with you, as I’ve done some of my own research regarding user ids. However, I disagree with your last statement; Applab.user is incredibly vulnerable, and I can set my own user id to whatever I want (for example, I made a script that automatically sets my id to “heroku”). The same goes for user.isSignedIn - if I wanted to change it to true, I could just as easily do so without the program knowing any better.

Code.org in general has a horrible security system, and the only way for them to fix it is to do a complete overhaul of their entire app. The best way to get around this is to develop your own features to keep your projects safe and secure. If you ever need help with that, you can and know where to message me :).

-heroku / letti

1 Like