Whenever I see something like this I just laugh because you’re exactly right. Something isn’t being handled properly and their dev team just proved they don’t know how to do some basic handling. Every API library in JS and restful API I know of handle special characters. If they wanted they could base64 encode it over the wire. Then you’re exactly right, if the database “can’t handle it” more than likely it’s a home spun database connection where they’re serializing it themselves (which even then this is solvable), but even then that proves that they make poor choices.
Sometimes I wonder if I’m even fit for employment as a developer and then I see shit like this where I wonder who and what happened for this to even become an option?
This is like when I was in my twenties working at a crappy grocery store with a MoneyGram inside of it. I live in Washington state, and at the time, if your last name was less than five characters, you would have asterisk’s in your license number. The MoneyGram system wanted people’s license numbers but was unable to recognize a license with an asterisk. It happened pretty rarely, but it always happened to people whose last names were four characters or less long. Five letters in your last name and you were gold. To make the transactions happen, I would just do the whole license number minus the asterisk.
Anyway, Washington changed how it generates license numbers so its a moot point anyway but I don’t think MoneyGram ever spent a dime to fix this since it only affected a small number of people in one US state.
Some states base it on your name in some ways. Mine used to have (maybe still do but I don’t live there anymore) letters from first and last names plus birth date as most of the number. I assume if you change your name your number changes as well.
Seems to be they’re dropping the passwords in the database in plain text, but they’re deathly afraid that someone will drop a '; in there or something and the insert will break.
Notwithstanding that storing passwords in plain text is a slapping with the 10 foot rubber chicken, but mysqli_real_escape_string() or any number of other similar solutions are indeed a thing that exists. A prepared statement would work, too.
but mysqli_real_escape_string() or any number of other similar solutions are indeed a thing that exists. A prepared statement would work, too.
You make it sound as if a prepared statement is a last resort. I would turn that around: as a rule always use prepared statements when dealing with user input. It’s very easy to forget a single call to mysqli_real_escape_string().
I was thinking more along the lines of the types of laziness/ineptitude most likely present at wherever OP’s example were being written. Escape string is one line of code for this whereas preparing a statement is like five.
But really they should just be hashing it. Then the input doesn’t matter.
Whenever I see something like this I just laugh because you’re exactly right. Something isn’t being handled properly and their dev team just proved they don’t know how to do some basic handling. Every API library in JS and restful API I know of handle special characters. If they wanted they could base64 encode it over the wire. Then you’re exactly right, if the database “can’t handle it” more than likely it’s a home spun database connection where they’re serializing it themselves (which even then this is solvable), but even then that proves that they make poor choices.
Sometimes I wonder if I’m even fit for employment as a developer and then I see shit like this where I wonder who and what happened for this to even become an option?
Always remember there is someone much cheaper than you who will do a much worse job, but be more arrogant about it
Fuck I’m literally one of the cheapest, all I’m asking for is 700-800 dollars a month
Exactly, the database should never even have to handle the password in it’s original form and hashing algorithms don’t care about special characters.
This is like when I was in my twenties working at a crappy grocery store with a MoneyGram inside of it. I live in Washington state, and at the time, if your last name was less than five characters, you would have asterisk’s in your license number. The MoneyGram system wanted people’s license numbers but was unable to recognize a license with an asterisk. It happened pretty rarely, but it always happened to people whose last names were four characters or less long. Five letters in your last name and you were gold. To make the transactions happen, I would just do the whole license number minus the asterisk.
Anyway, Washington changed how it generates license numbers so its a moot point anyway but I don’t think MoneyGram ever spent a dime to fix this since it only affected a small number of people in one US state.
Are you saying that your driver’s license number contains your name? Do you get a new number if you change your name?
Some states base it on your name in some ways. Mine used to have (maybe still do but I don’t live there anymore) letters from first and last names plus birth date as most of the number. I assume if you change your name your number changes as well.
Seems to be they’re dropping the passwords in the database in plain text, but they’re deathly afraid that someone will drop a '; in there or something and the insert will break.
Notwithstanding that storing passwords in plain text is a slapping with the 10 foot rubber chicken, but mysqli_real_escape_string() or any number of other similar solutions are indeed a thing that exists. A prepared statement would work, too.
You make it sound as if a prepared statement is a last resort. I would turn that around: as a rule always use prepared statements when dealing with user input. It’s very easy to forget a single call to
mysqli_real_escape_string().I was thinking more along the lines of the types of laziness/ineptitude most likely present at wherever OP’s example were being written. Escape string is one line of code for this whereas preparing a statement is like five.
But really they should just be hashing it. Then the input doesn’t matter.