shlumph

Do you mean mysql_real_escape_string? Wrap it. mysql_real_escape_string($Post_Username) More notes here, included suggested alternatives since mysql_* has become outdated. http://php.net/manual/en/function.mysql-real-escape-string.php

It sounds like $reason is always 0, then. If nothing is printing out. What happens when you var_dump($reason)?

Malakai isn't in quotes. That's one problem. Without knowing your DB structure, and the error you're getting, it's hard to tell what else could be wrong.

Agreed. Just store the User ID in $_SESSION. At first I thought you were persisting the User ID through forms only. That would be a big no-no.

No. Actually, when you use a framework and you are not a good programmer to begin with, you will end up with a bigger ball of mud than what you would have had if you hadn't used it. That's the story of my first real project (with an MVC framework). Starting with Symfony 2 or Zend Framework 2 is sound advice. Symfony 2 might be easier to get a grasp on at this point, since Zend Framework 2 just came out and may not have as thorough documentation.

That looks like it should work. Try debugging, maybe it's failing somewhere: $r = mysql_query($q) or die(mysql_error() . '<br />' . $q);

Yes, you're right it would be difficult to manage. I'm not sure of the nature of the code, so this might not be a valid option. But, maybe you could just make it a feature in your main code base. Then the feature can be toggled on/off in a config file or something. That way, if another company wants the feature, they/you can simply toggle it on.

Must be pretty distributed to bring a friggen hosting company down. LOL.

I would create a separate branch for the special code. And keep it up to date with the main branch.

Interesting. I'd be curious to see a comparison with Symfony 2.0.0 thrown in as well.

Here's some more information: http://www.php.net/mysql_real_escape_string

It's more than likely because you aren't sanitizing the data before running it through your INSERT query. If someone inserts a quote as part of their user input, it probably breaks your query. Make sure you run mysql_real_escape_string on all your POST values from the form, before using them. This should fix things for you. I would also suggest inserting the user before sending the email. And checking if the user already exists before inserting them.

You can use the $_GET variable as part of a condition, if that's what you're asking. You can use it just like any other variable.

Yes, a little vague. Are you thinking something like this? if($a == $b) { $data = getSomeData(); }

Try printing out $salt, $hash, and $final and see if they are what you expect. In the case for the user above, it should have been: 7c3396065c8e7758f8afdeb57c53349e // $salt 1d509fa8ebe0323350b548f76ba0cbf7db8b912deeb0249b4d32a4368b400914 // $hash 7c3396065c8e7758f8afdeb57c53349e1d509fa8ebe0323350b548f76ba0cbf7db8b912deeb0249b4d32a4368b400914 // $final It may be that your database column isn't large enough to hold the full $final. Or your $salt is returning null.

I think this is what you want: $correctHash = $row['password']; //This should have the prepended salt, along with the hashed password + salt $salt = substr($correctHash,0, 64); //If the salt is always 64 chars, then this should be OK $testHash = $salt . hash("sha256", $salt. $pass); //Should match up with $correctHash if ($testHash == $correctHash) However, if it doesn't work, I would suggest echoing out your hashes/salts to debug. It should be easy to identify what's going wrong seeing everything printed out.

You'll need to do the same hash algorithm for logging in as signing up. And if your generating a random salt when the user is signing up, how are you going to log them in without knowing that specific salt for the user? Edit: Nevermind, I missed that you're prepending the salt to the password.

As mrMarcus suggests, their username would probably be the best. If you want a way to do it where the user doesn't have to be logged in, I wouldn't uniquely identify them with just their IP address, though. NAT could mess this up.

The only time I ever create static variables/functions is when I want to set defaults for a class. At least, that's what I aim for. So later on, if I initialize the class and don't inject anything, the defaults will be used. Something like: <?php //Assume Table extends Database class Table extends AbstractDatabase{} //When bootstrapping the application $pdo = bla bla AbstractDatabase::setDefaultAdapter($pdo); //Later on, in a different section of the app $table = new Table(); //Uses default adapter $newPdo = bla bla bla $table = new Table($newPdo); //Uses the injected PDO

The dev guide has everything you need to know to get started: http://developer.android.com/guide/topics/fundamentals.html

From what you've shown, I don't see anything that could be causing the problem. Is the 'scripts/func.php' included multiple times per request? Namely, is conn() executed multiple times per request? There should only be one DB connection per request, if all your queries are going to the same DB host. This is the first thing I would check. If that's not the case, you can always increase the number of connections: http://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html

Just use auto_increment and then wherever the number is displayed, use base64_encode to make it look "cool". If you need to extract the "cool" number to do a DB lookup, use base64_decode

As mentioned, you cannot have multiple inheritence in PHP. Assuming that you have one gateway set up as ClassA, and another as ClassB... It sounds like you want a factory to decide which class, A or B, to spit out. You could include the randomness in the factory: class Factory { public static function create() { $class = null; $number = rand(0, 1); switch($number) { case 0: $class = new ClassA(); break; case 1: $class = new ClassB(); break; } return $class; } }

I remember having to do things like this for Programming 101 assignments. Good luck.

I think this may help you out, Matt. SHA1 and MD5 are one way hash functions. Meaning, no one has been able to take an MD5 string, throw it through an algorithm they made, and get the clear text. At least not that I know of. However. Some people have a database of words and their corresponding MD5 string. They simply iterate through a dictionary, store the clear text and then the hash of the clear text. So, once they steal all your user's passwords hashed with MD5, they can simply look in their database to see if there are any matches. It's called a reverse lookup. http://www.md5rainbow.com/ That is at least partly why having salt is important. Because these common reverse lookups won't work.