For the amount of text in a text box (string.len amount) into text. So, per-say string.len amount was 5, the text would turn to -----
I’m currently out of ideas on how to do this.
I’ve asked around to a few of my programmer friends and I haven’t been able to find a solution. If any of you are able to find or know a solution let me know!
(For context, I’m making a “beta account” thing for a group. Which once I’m done I’ll most likely be posting about it here on the Dev Forum)
print(string.rep("-", 5))
Try using
TextBox:GetPropertyChangedSignal(string property)
Then, every time a new character is added, concatenate that with a saved string variable and replace the TextBox’s Text with hyphens.
If you’re just trying to replace the text with dashes, you can try text:gsub(".", "-"). This should replace all characters with dashes.
@posatta @Blokav @GGGGG14 @AbiZinho
Thank you for your replies and thank you for your help and I now have it working!
In addition, if you wanted to actually store the guessed password, you can store it as so:
local TextBox = your.TextBox
local GuessPassword, Length = "" , 0
TextBox:GetPropertyChangedSignal("Text"):Connect(function()
local CharsInTextBox = #TextBox.Text
if CharsInTextBox < Length then
GuessPassword = GuessPassword:sub(1, #GuessPassword-1)
else
GuessPassword = GuessPassword .. TextBox.Text:sub(CharsInTextBox)
TextBox.Text = string.rep("-", CharsInTextBox)
end
Length = CharsInTextBox
end)Yeah, or you could make it like this (it may be more efficient)
passwordBox = GUI.PasswordBox -- Let's assume we have a GUI with a TextBox named PasswordBox containing the text "Password" and ClearTextOnFocus set to true.
local RunService = game:GetService("RunService")
local realPassword = ""
local prevLength = #passwordBox.Text
local functionIsReady = true
passwordBox:GetPropertyChangedSignal("Text"):Connect(function()
if functionIsReady then
functionIsReady = false
local text = passwordBox.Text
local currLength = #text
if currLength > prevLength then -- If anything is added to the TextBox, do this. (Only works with ONE CHARACTER at a time!!!)
realPassword = realPassword .. string.sub(text, currLength)
passwordBox.Text = string.sub(text, 1, currLength - 1) .. "-"
else -- If anything is removed from the TextBox (like the text box clearing or the player pressing backspace), do this.
realPassword = string.sub(realPassword, 1, currLength)
end
prevLength = currLength
RunService.RenderStepped:Wait() -- Debounce
functionIsReady = true
end
end)
You can do anything with realPassword after the player has entered their password.
Personally, I think Roblox should add a PasswordBox class, so the keyboards on mobile don’t store your password into the keyboard suggestions memory (although there is a hacky workaround for this problem by re-opening the keyboard every time a character is entered.
I can’t think of a use case where user-inputted passwords would be safer than verifying the player through their Player instance.
I personally believe that creating such a class might normalize that type of unsafe practice for newer developers (after all, if the engineers added it, they must mean it’s safe to use, right…?) and thus encourage substandard security practices – that would be a dangerous precedent to set.
I agree. It’s a cool looking aesthetic, but also the same type of thing that some hackers use to phish for accounts and passwords with fake Roblox login screens. (See all those “free robux” games that used to be widespread)
All valid points. Might rework it to have people be able to use just a username for random things and you’ll only be able to log in with your userid (player instance) and possibly be able to whitelist others.
I’ve considered doing a faux login screen with a forced username and then a password box that’s just useless, so that the entire thing is just an aesthetic and the important data is verified by the all-powerful server.
Imagine checking data with a local 
Hope that’s a joke, because client-side data checking isn’t inherently bad. Deferend’s case of a false login screen makes the system itself pointless to have but otherwise the concept itself of client-side data checking is actually quite powerful so long as the server is also there to step in. Once from the client for instant user feedback, then from the server if the client-side passes for the extra security later.
Login screens on Roblox are extremely pointless though. Just whitelist players if you need a working beta. We already have Game Access Permissions that prevent a user from playing a game without play/edit/manage access. (See below. Thanks for the tidbit!)
Yes yes, some people attempt to check all data with local scripts (don’t ask me why) but yes. All good points. This post definitely has gained traction.
Oh and to add on. All accounts are saved on creation in a database.
I’m going to have to disagree.
Lua Learning has a team of people who moderate tutorial submissions. This team is whitelisted by UserID. However, if a moderator’s Roblox account is stolen (phishing, left it logged in, whatever) the theif would have the power to accept inappropriate submissions and ruin Lua Learning, possibly getting it content deleted.
As an additional layer of security, those whitelisted accounts have to login to the moderation system. Their password is cryptographically hashed and salted, and logins are exponentially rate limited, eventual lockout, the whole nine yards.
This way, account thieves have to steal the moderator’s Roblox account and their Lua Learning password in order to cause damage.
TL;DR: Important for extra layer of security for vital admin/mod systems
Indeed, indeed. Thank you for your reply as well. That does remind me. Not all accounts that are saved there are “Staff Accounts”. But the ones that are if you attempt to log into a staff account and your UserId doesn’t match the one saved as the “creatorid” you’re automatically kicked. (Currently have the staff be able to disable anyone’s account, reinstate it, make announcements, turn normal accounts in to staff accounts etc.