Here, Sup Forums, I've made a simple 8ball web app as practice to learn PHP and MySQL, and I've decided to share it with you guys. It will remember past questions and return the answers it previously determined.
The web page shows up properly in every browser and contains absolutely no nonfree javascript or any scripts you're expected to run for that matter. For people who prefer it, there is an even simpler method to ask the magic 8ball questions. Just POST it as q to nonfree.pizza/8ball.php and it will respond with no HTML, just the answer. For example:
$ curl -d q="Should I install Gentoo?" nonfree.pizza/8ball.php The 8ball says: Do you really need me to tell you that? $
This saves on bandwidth if you're in a location with bad internet or an applications developer.
Suggestions welcome. I hope at least someone on here finds value in it.
root@server:~# curl -d q="will i get pussy tonight?" nonfree.pizza/8ball.php The 8ball has determined: There's no question about it. root@server:~#
thanks 8ball
Kevin Reyes
>Here, Sup Forums, I've made a simple 8ball web app as practice to learn PHP and MySQL
>Web app
Also why the fuck do you need a database or PHP for something that could be done in Javascript? Or a single line or perl?
Caleb Peterson
>javascript Why would I want to trust the client to determine the answer? I'm storing the answers for future responses, so why wouldn't I do it serverside?
Jacob Roberts
>Why does the botnet want me to starve? It wouldn't be right for me to reveal this.
Nathan Perry
ok
Sebastian Moore
OP do you want to suck dick?
Isaac Bailey
reminder that this website logs your inputs and it has no privacy policy, so don't go putting shit like your SSN in there
Tyler Wilson
If you use POST I can't see anything fyi Questions are stored as hashes
Logan Reyes
then how did you know that someone did or did not attempt SQL injection
Lincoln James
Just look at the questions in database.
Owen Jackson
but you said they're stored as hashes
Cameron Adams
Because they used HTTP GET. I'm watching nginx's access logs, and anything asked via the website uses GET, so if you want to ask something personal, you should use the POST API instead. Questions are stored as hashes, to prevent SQL injects and in case the database gets compromised. That's not me.
Evan Jones
Believing what people tell on the Internet. Are you retard?
Joshua Ward
>hashes, to prevent SQL injects lol
Charles Nguyen
I didn't feel like doing anything fancy like parameterized queries or stored procedures for this. Hashing just werks.
Eli Gonzalez
You can escape the string. PHP has a function for that.
I figured I wouldn't waste the cycles, since the hashing was for security reasons/practice anyway. If everything's hashed before lookup, why bother sanitizing?
The only touching up I do is trimming extra spaces and other duplicate checks, and htmlspecialchars() for when the question is added to the page.
Ethan Phillips
>if you want to ask something personal, you should use the POST API instead. Why would I want to ask your shitty website something personal?
Jacob Lewis
I agrre that hashes protect from SQL injection, but I would never use hashes to protect from injection. "It's an implication, not an equivalence."
Carter Ramirez
>parameterized queries >fancy
Hashing is slow and costly
Nathan Williams
Someone did ask it "my SSN is XXX-XX-XXXX" which isn't a question but whatever floats you're boat I suppose. Hashing is supposed to be slow and costly. Since there's no reason to store the questions themselves, I hash them in case some clever cracker steals the 8ball's answers and reveals them to the world.
Zachary Diaz
You could also use prepared statements which are just as quick to write as a normal statements.
Escaping strings from the client does not guarantee protection against SQL injection.
Dylan Torres
>Escaping strings from the client does not guarantee protection against SQL injection. How? I'm interested. Explain to me.
Landon Ross
I will probably play around with more secure methods, like I said this was a simple practice and the first PHP app I made of any significance.
Henry Rivera
At work and posting from phone, so I cannot link examples or sources. You can Google this yourself.
In short, when I started doing php development (2 years ago), I learned about SQL injection and how to prevent it/best practices.
One of those best practices is to not escape strings. It can mess up input data and mess up displaying the data later on a webpage. On top of that, there are tricky ways to get around escaped strings to perform SQL injection such as abusing Unicode. There are multiple ways to escape strings in php for dB insertion, each way has different caveats.
Because of this, I decided I would just use prepared statements on all data that comes from the client and not worry myself over escaping or sanitizing client data.
Easton Ross
>displaying the data later on a webpage You have to unescape the string for displaying.
>escaped strings to perform SQL injection such as abusing Unicode It won't mean that escaping is a bad idea, it would just show that the escape function is incorrect. And the spec of the database must be read to see what can begin and terminate a string. And the database must obey its own spec.
In any case escaping is not a bad method. There just bugs that need to be fixed.
By the way the MySQL escape function in PHP is reliable.
Xavier Bell
>You have to unescape the string for displaying. I am aware. When you start escaping strings, you'll have to do it to all strings to ensure consistency as well as ensure you're unescaping all data retrieved from the db.
>In any case escaping is not a bad method. There just bugs that need to be fixed. Escaping works as intended. It can have some unintended results though, so I avoid it.
>By the way the MySQL escape function in PHP is reliable. One Google search brought up an example where injection can get through. They exist but they're very rare edge cases.