Jessica

http://php.net/date

Edit: read too fast. On second thought, try generating a PDF with the info. That way, it will look the same in all browsers, will have the same spacing and font size, etc. PDF is great for that sort of thing. And php's pdf functions aren't that hard to get the hang of.

Good point

Unless you allow the user to enter the time of day they were born, it won't be accurate. You'd also have to account for where they were born, where they are, and where your server is. Time zones. I'd use timestamp() instead of messing with the year and then multiplying it, but without the other info the closest you can be is within 24 hours I guess.

There are actually some ways to hide your JS code from really being viewed if you generate it with PHP. However, the only one I ever considered relies on what is sort of a glitch in php's session handling. (or something like that, I haven't played with it in forever)

Uhm, not to be rude but you couldn't find this in search? A search for decimals turned up a few related posts.

The actual characters which are inserted, I'm not storing them in the salt field is what I said. Those characters are not stored, as opposed to a salt which has to be stored. I'm storing numbers which don't mean anything to someone looking at the database.

http://us.php.net/natsort

You don't, you remove the random stuff from the hash which is stored in the database, and compare that to the hashed password they entered. So I have three fields: username, salt, password. (Well obviously I have more but these are what matter right now.) The user enters their username: wormy Their password is apple, so they enter apple. The SQL then gets the stored hashed and salted password for user "wormy" which is 1f9f387ef3a0be27bc74f6c49b3e3b4b7e1a0c6728957f and the salt which is 520 310 21 45. The code then removes all of the random characters which were entered to get the MD5 hash which is: 1f3870be274f6c49b3e31a0c6728957f The code then runs md5 on the user entered password: apple. 1f3870be274f6c49b3e31a0c6728957f 1f3870be274f6c49b3e31a0c6728957f And they match, so it's the user! Maybe doing a combination of this and the regular salt method would work best for me. Of course, I think there would be ways to do a salt without having to store anything extra. say your salt was added before the password is hashed. Our user Wormy wants to use the password "apple". So before it is hashed we add other account information which is stored, such as their userID, their email, username or username length, etc. This is information we need to store anyway, and someone who has our database will not see a "salt" field and know that the passwords are salted, without seeing the code. The user still needs to know their password to login, but we simply add on the info before hashing it and comparing it to the DB. Just some other ideas. Gath - not if your database server is not the same as your file server. There are plenty of ways people could gain access to the DB and not have the code. They could also have only some access such as SELECT but not UPDATE or INSERT, and would need to decrypt a password. *shrug* I just wanted to explore using salt, and this was the idea I came up. There is no perfect solution to security but we can still add little tricks, right?

Where is your SQL? What I would do is select them all out ordered by first the category and then the product. SELECT * FROM table ORDER BY category, products Then do your loop something like this: (pseudo code, make sure to edit it to work with your code. <?php $lastCat = ''; while(//there are more rows){ $cat = $row['category']; if($cat != $lastCat){ // it's a new category print $cat; } $lastCat = $cat; print $row['product']; } ?> You really should have a seperate categories table and just use the ID to reference what category it is in the products table.

Well, post your code.

No, I store how many characters and where they are. That is how I know how many and where to remove. Thus, the salt fo the above is 520 310 21 45.

I don't think you understood what I was saying, it wouldn't let them know characters in the password... I would actually think it would make it harder to tell that it is md5. Say the password is 'apple'. The md5 would be 1f3870be274f6c49b3e31a0c6728957f Then the salt was 520 310 21 45 It would insert random (and not stored anywhere) strings of characters that were 5 long at spot 20, 3 long at spot 10, 2 at spot 1 and 4 at spot 5. So the end would be for example: 1(f9)f387(ef3a)0be27(bc7)4f6c49b3e3(b4b7e)1a0c6728957f Which is stored as: 1f9f387ef3a0be27bc74f6c49b3e3b4b7e1a0c6728957f

Uhm, it will always be "var". It is not x, because out takes the argument $var, not $x.

I found your problem:

your query is failing. Try this: <?php $sql = "select timecounter from admin where username='$username'"; $timecounter_result = mysql_query($sql) OR die(mysql_error().' Query: '.$sql);

I have been reading up on salting for password storage. Most of the articles I've read said to add the salt to the password and then hash it. Before I had read too much, this is how I was planning on doing mine. Can anyone offer advice as to if this will work as well or not as the regular method? I was planning on adding random characters to the hashed password. So it would be like: $pass = md5($pass); $salt = rand(0,9).rand(0,strlen($pass)).' '.rand(0,9).rand(0,strlen($pass)).' '.rand(0,9).rand(0,strlen($pass)).' '.rand(0,9)rand(0,strlen($pass)).; Now, each of the random number pairs will stand for how many random characters have been entered, and where in the string they were injected. I just thought this might be a bit harder to decode than the original method. Am I off my rocker?

I think it's a good idea, because it keeps your code organized. However, you have to pay attention to your errors and make sure you know what page to edit

If you lookup the function in the manual you'll see why that won't work. The function returns the new string, your code will not accomplish anything.

I'd do them alphabetically. Easy to sort them that way.

If you are using a certain type of submit button such as an image, I think IE has issues. If it is a regular button it will work outside of a textarea as others have said.

Because in the HTML you should write "option" not ".option" the . in the css indicates a class, like how a # indicates an ID. You don't put it in the HTML part. Also, next time use code tags please!

echo "<meta http-equiv=\"refresh\" content=\"20\" />" That's still HTML doing the work, dur. You can make PHP print anything you want but it doesn't mean PHP is making the page refresh. PHP is just printing the HTML which makes it refresh. If you don't know the basic HTML parts, you can't do it. There is no PHP function to do that, it is HTML no matter what language you use to print the HTML

Which is still not PHP, it's HTML.