Hi.
So I’ve been trying to make a “username and password” type script, like the ones you’d find on a website where you need to log in to use your stuff.
I wanted to make it so you can’t register a name that somebody already has, but I can’t seem to make a for loop with a database.
I’ve tried everything that made sense, like :GetAsync().
Is it possible?
You could save it using their name as the key (or userid, if it applies to your situation)
Then you’d use :GetAsync to see if there’s anything saved for that name
As far as “looping” through a datastore goes, you can use OrderedDatastores (These aren’t necessary for the above solution)
You could make a different datastore for each username like this:
datastore:SetAsync(username)
and to check if the username is taken all you would have to do is call GetAsync with the username and check if it is nil.
Good idea. I’ll see if it works out. I’ll send a reply back if it does.
Datastores are like big dictionaries that are stored on roblox’s servers. It is just like a table in the sense that each datatstore saves a key and a value. If the key == the username then you can easily do :GetAsync(username) and pcall that. If it returns nil then you know it doesn’t, if it returns a number or something, that means it is a password associated with an existing key (aka the username is taken). You gotta be careful with how you implement failsafes, as if you mess something up and it manages to suceed, (aka the person calls a remote event but the checks were client side initally), then it will override the previous data. If you need anymore help, just let us know here, I’d be happy to help out. 
Suggestion worked wonderfully. Thank you.
Your suggestion kind of worked, it shot out an error so I just switched up it saying “nil”.
No, you can’t iterate through a DataStore. If you pull an array or table out of a DataStore you can iterate through that table, but overall you cannot iterate through every existing key of a DataStore.
@MallocByte While this is a viable solution, be mindful of DataStore limitations. Such a system like the one you proposed seems like it’ll waste valuable request limits quickly.
What’s even the use case here? Can’t you just save stuff under a player’s UserId and skip the username-password thing? I can see a lot of issues with something like this in the first place.
I did use a player’s userid to store, but I needed this way.
I’m not really that experienced in datastores, so it’s expected this is a mess-up. But I need it so if a player registers under the same name they can’t, and they can also log in but they need to be able to get in to other accounts to help another player with something on their account. There’s not really any issues.
Does this mean that the same Roblox user can make multiple accounts in VRBlox?
Yes, and they are able to log into those.
What exactly is the use case for this?
Storing passwords is something that should be done very carefully. I’d try to avoid it altogether if I was you.
If not done right, you are effectively exposing large amounts of highly sensitive data to anyone who has access to Roblox datastores (i.e. Roblox employees), along with anyone who can get that data through illegal means. Plus, there are no guarantees about the actual data being transmitted to/from Roblox servers. AFAIK it isn’t even encrypted, meaning anyone in between Roblox’s servers and the client could snoop in and read the password.
Also, from experience, people tend to reuse their passwords everywhere, or end up making bad passwords altogether. This ultimately defeats the purpose of your login system anyways.
How so you plan on storing the passwords, will you hash them or save them as a string?
I have to agree with sayhisam1, storing passwords seems a little bit sketchy and odd to me. Wouldn’t it be better to just allow users to create new accounts as they will and authenticate them with their UserId? The only real reason you would need a username password system on your game is if users were permitted to share accounts (which your warning clearly states isn’t allowed).
If you read the warning again, if they can be trusted on your account they may be let on it. They are permitted.
It has already been solved, but by string.
Oops you’re right, I misread the warning. In the end though the use of passwords still seems a little bit questionable, you could just as easily have users select who they share their resources with (like the whitelist many games use, except a little bit more permanent). That way players can still work together and share with UserId authentication rather than passwords.
Good idea. With the thought of this, I could add a 2-step verification type of thing by using User ID authentication so whomever is logging onto the account has to verify using it. It’s better so if the databases get leaked people need to identify.
I’m not sure what you mean by having UserId as 2-step verification. What I’m trying to say is that there’s no need for Username/Password combos for your game, users can simply type in the username/UserId of others they want to share their resources with. When users join your game, they’ve already authenticated themselves by joining on that account. Using that account’s UserId is the only authentication you need.
Sorry that I’m really bad at explaining this, I’m not really sure how to put it in easy terms.
