Rushyo

"http://twistablepie.servegame.com/cype/?cype=main&page=ranking&order=name" Allows me to check existence of field names for that table. There seems to be quite a few holes in GET data filtering.

active.php is always returning "There was an error in the activation of your account. Please email the site admin and describe your problem" even with valid credentials.

Initial observation: $EnemyDamage3= round($EnemyDamage3 / 1.25); Since you set EnemyDamage3 to 0 when there's insufficient Chakra, you're going to cause a division by zero. Honestly, I'd be surprised if anyone has time to dig through all that code. Have you tried a 'dry run'? You will probably find any bug quicker than we will.

http://www.phpfreaks.com/forums/index.php/topic,232470.0.html The big sticky at the top of the forum. I just tried using your site in a normal capacity with only slightly anomalous results and it seems very eager to throw up internal server errors.

An echo replaces a statement with whatever it returns... thus: <td colspan = "5"><input type="text" name="DESCRIPTION" value="<?php echo "{$row['DESCRIPTION']}"; ?>"id="DESCRIPTION" size="100" /></td> Will return: <td colspan = "5"><input type="text" name="DESCRIPTION" value="14""id="DESCRIPTION" size="100" /></td> Not terribly correct HTML. You should use encoded characters, see http://uk.php.net/html_entities. For example: $strDesc = html_entities($row['DESCRIPTION'], ENT_QUOTES); The ENT_QUOTES is important, otherwise quotes won't be converted

By default, div tags are block elements. Thus they always reside on their own line. Why do you need them in divs? Would a span not suffice?

"md5 hash ur cookie variables" Unsalted it wouldn't offer any viable protection as is, since the user could just md5 the username he wanted. admin -> 21232f297a57a5a743894a0e4a801fc3

mysqli_real_escape_string() will work for most purposes.

if ($_POST['password1'] != $_POST['password2']) { die ('Your Passwords Do Not Match. Please go back and try again. Thank You.'); } die() ends execution. Hence it would never get to the include() statements.

As the errors state: Failed opening 'config.php' for inclusion Failed opening 'opendb.php' for inclusion These files either do not exist on the server or your server does not had read access to them.

The PEAR library has a mail function which is quite powerful.

"also can someone tell me how i would achieve gettings the users ip logged each time the User Account logs into the system? please and thanks" <?php $strIP = $_SERVER["REMOTE_ADDR"]; ?> Then just put $strIP in your database. Note that this value is pretty easily faked.

Eight characters and 'easy to remember' are not mutually exclusive. Regardless... if the user wants to stick their password up, that is generally their problem rather than yours. If the user's password gets stolen because somebody brute forced your website though, they'll tend to hold you responsible for it regardless of the merit of the argument. It doesn't make more than a negligible difference in the context it is being suggested.

"i set max characters to 50 and everything works now... thanks.... now what else could i do to make the names and passwords more secure??? " MD5 hashes are always 32 characters long. Ideally, you should use SHA256 rather than MD5. They're not hugely different, but the former is certainly more secure. You should create a very long string to use as a key and add that key to the end of all passwords. You should also create something unique for that account (preferably based on as many factors as possible such as time, the user's IP, and other things.. the more random the better) and add that, also hashed, to the database alongside the password. So it'd be like this: <?php $strLongKey = "uihf4ef...adoijwudn;" //This can be anything, feel free to type it by hammering the keyboard... the longer the better. $strSalt = sha256(time()); //This just uses the current time... add more variable stuff here to increase entropy! $strPassword = sha256($strSalt.$_POST['pass'].$strLongKey); //Do stuff mysql_query("INSERT INTO users (username, password, salt) VALUES ($strUsername, $strPassword, $strSalt"); ?> To login, repeat this procedure but instead of generating a new random salt, get it from the database. The key must be the same each time. Now someone who breaks into your database won't have the key... and someone who breaks into your application won't have the salt. Bearing in mind this is just password salting alone. Password constraints (minimum 8 characters, using a range of characters) is very important as well. To make a secure application requires significant expertise. Most companies will hire a professional to audit and/or certify their systems.

As I asked earlier: Are you sure the $_POST vars are getting through to the script fine? Try echoing your SQL statements to check what hash is actually getting through.

Are you sure the $_POST vars are getting through to the script fine? ""it registers the username and the md5 password just fine... i checked my database... but when i go to log in,,, it keeps telling me that i am not registered......how much further could i go with security past md5 once i get the md5 to work?" Quite a long way really, but salting suffices for many purposes. Just add the username to the password being md5'd... eg. md5($password.$username);

If you plan to use MD5 as a password generator, I recommend you look up 'salting' to make it more secure.

allow_url_fopen is disabled. I'd say run phpinfo(); to look at your server's PHP settings, but I've used Hostgator and know they have it disabled. It poses a gigantic security risk, so any server host that has it enabled is reasonably idiotic. By the way, I would recommend you switch from Hostgator. They're rude, coniving and technically useless.

"the //table field is a note for display purposes here only. " That is not the problem. The problem is your SQL query ends here: mysql_query("SELECT terms FROM beta") Anything else is not being executed as a query and will cause a parse error (except the obligatory ; in the latter case)

http://www.imagemagick.org/discourse-server/ Eeesh.

The reason for these notices (the 'weakest' form of error) is that when combined with register_globals they pose a significant security threat. That coding style is also the cause of many coding mistakes.

<?php if(mktime() > mktime(0,0,0,1,10,2009)){ exit(); } ?> It doesn't much analysis to realise this bit is likely to be problem. What on earth is it designed to achieve other than killing the site?

"Suggestions? I've never used drupal or other cms systems, so anything thats simple would be great!" They are the simple solution. You shouldn't have taken on the job if you couldn't do it.

"Is there any open soure all in one editor to write e.g. a simple e-commerce online shop using ajax and php?" A text editor and a lot of learning. Seriously.

http://uk.php.net/manual/en/function.strtotime.php This should turn it into a unix timestamp (an integer value, based on the number of seconds since 1970 IIRC). Perfect for storage and use by just about anything. date() accomplishes the reverse.