davidannis

Looks like you want to add the same amount each year. A trivial change to Barand's program: $age = 30; $contribution = 500; $rate = 0.06; echo '<pre>'; printf('%3s | %10s | %10s<br>', 'Age', 'interest', 'capital'); for ($y=$age+1; $y<=65; $y++) { $capital += $contribution; $interest = $capital*$rate; $capital += $interest; printf('%3d | %10.2f | %10.2f<br>', $y, $interest, $capital); } produces the following output: Age | interest | capital 31 | 30.00 | 530.00 32 | 61.80 | 1091.80 33 | 95.51 | 1687.31 34 | 131.24 | 2318.55 35 | 169.11 | 2987.66 ...

http://www.php.net/manual/en/book.session.php

My guess is that the content of $c_date is mangled because I don't know where or how $phptime was set. I now understand that but since the OP said it is not really needed. That said, I think that the advice to find the mysql error is a good.

Kids fed, bathed, and sent off to bed, so now I have a chance to explain why I don't think giving away the salt matters. This is my understanding of how it works. When you hash a password, you are not encrypting it - you are calculating a value based on that password which is unlikely to be duplicated by performing the same calculations on a different password. You can, however, have another password that produces the same value (that's called a collision). Since more than one value can produce the same result it is not possible to reverse or decrypt the passwords. The issue is not hackers decrypting the password it is that they try brute force attacks, trying lots of common or short combinations to see if they can get something that produces the same hashed value. Let's take an example of a file which falls into a hacker's hands that has a username and hashed password under 3 scenarios: If Joe Hacker gets an unsalted password file he can look at the values in that file and find common ones (let's say .3% of 10,000 users use "password" as their password). Joe has databases with dictionaries hashed using all the common algorithms. He sees 30 hashes are !@#$%^&* and finds in his database that sha1 produces that as it's hash for the password "password". He realizes he has an unsalted sha1 hashed file. Sally used "superior" as her password, which was unique among the 10,000 users but Joe sees that hashed to "123456789" and looking in his table of sha1 hashes he sees that the password superior will hash to that value. By using an unsalted table it made it easy for Joe. In scenario 2 Joe gets the file but every password was salted with the same set of characters. Joe sees 30 values that are identical but since that value is not in his common hash values database he needs to figure out the salt and rerun the dictionary. A daunting task. Nonetheless, he knows something about commonly used passwords and tries a few hundred of them against the thirty accounts with the common hash value. Once one lets him in he knows all 30 use the password "password". He can then run password with random salts through the algorithm until he figures out the salt. Then use the salt that he figured out to run the entire dictionary and Sally (with much more work) is still compromised. In scenario 3 Joe gets the same file, hashed with a different salt for each user. He also gets a note saying that the salt is the username. He would have to run the dictionary against each account with a different salt. It would be time intensive and breaking one password does not help him break the next. Someone who used a secure password (long, not in a dictionary) is unlikely to have his account compromised by Joe. Hash algorithms rely on the fact that it takes a long time to run lots of possible passwords through them. Using a unique salt means that hackers can't take the shortcut of running the dictionary once against all accounts in the database. If the hacker knows the salt for a particular account though, he can crack that account no faster than he could without knowing the salt, unless he only needs to try weak passwords because he still needs to try the same number of combinations of random characters to find one that gives him the right hash value.

I realize that my post above would gain a lot from a paragraph on why "giving away the salt" (which actually isn't what you're doing by leaving the first 29 characters) isn't that big a deal but I have hungry kids and a dinner that will take too long to cook. I'll come back with an extended comment later.

I've done a little research and suggest that you be very careful about using your own salt instead of the blowfish salt and removing the first n characters of the hash. Here's why I think so: The blowfish generated salt is meant to be random, so that it is unlikely that two entries in the database are hashed with the same salt. I do not believe that an MD5 hash will be any more random than the one generated by blowfish. More importantly, removing the first characters of the salt also removes some information that you may want later. Here's why A description of what the start of the hash is Now if you remove this you make it harder for an attacker to try to get the salt back, but you also lose the algorithm version and the cost that the password was encoded with. Now, if the recommended cost (the number of iterations that the hash goes through) changes you are stuck. You can't do new passwords with the new cost and gradually migrate your users as they change passwords. If you upgrade php and the default cost changes you may suddenly find your code no longer works for stored passwords. Similarly, you can't change the algorithm (in fact the $2a$ in my example from stack overflow is deprecated to fix a security issue). If you have 1,000 passwords using $2a$ and add one using the new $2y$ you don't know which method to use. In your shoes, I'd choose the most secure algorithm the community has come up with (which you have) and use it as is, not try to improve it since I recognize that I would need a lot of expertise that I don't have to be sure that I'm not messing things up that will bite me later.

jamezz98: You taught me me something new too. I thought that the html standards required quotes around all values. I looked it up and found out that they are just recommended.

You need quotes around the value in your select <option value="<? echo $row2['id']; ?>"><? echo $row2['school_name']; ?></option> and I don't understand why you have the line below it: <?php $school = $row2['id']; ?>

Ignace, Not to be argumentative with a moderator but: that is true until the OP stores the variable we're talking about, $password, in a database here: $db_insert = "INSERT INTO users VALUES ( NULL, '$name', '$email', '$username', '$password', '$telephone', '$postcode' )"; mysqli_query( $dbc, $db_insert ); // performs query on db If I follow your argument to a logical extreme, after hashing my password I could save lots of space by just storing the first byte. Of course, in a brute force attack, the attacker would get something that hashed to the same first byte in half the time that if I took to get something that would be the same as if I stored two bytes...

Haven't had a chance to look at all of the code but why: function generateHash( $salt, $password ) { $hash = crypt( $password, $salt ); $hash = substr($hash, 29); return $hash; in generate hash not use the whole result? Disk space is cheap and an extra 100 bytes makes things more secure.

Do you have a </table> ? Can you post the source (html) of the output?

You can set the date with just $c_date = date ("Y-m-d"); I have no idea what is in the second variable in the date function but you don't need it. You should also backquote the field names. I think DATE may be reserved.

What is not working? Do you get an error message?

AyKay47 is right, you are POSTING keys not values.

In your foreach if in_arrray ($toractions, $callstocation ) {do your stuff here;}

Can you comment out the refresh and see what is in $_REQUEST by adding print_r($_REQUEST); Do you know that your SMTP server on the local machine is working? David

line 164 reads line 0, does nothing with it then 166 reads line 1. just kill 164.

Sorry after a night's sleep I looked at it again. getElementbyid(oppid); needed to be document.getElementById(oppid);

I assume that ct.sub_cat_id, sub.sub_cat_id AND mc.category_id are all INDEX fields. If not that's a place to start

if you need to see what your variables look like try using print_r($_POST); or print_r($_GET);

In your third (working example) you have no square brackets after the variable name - it is a variable not an array (which is what you want) and you use checked=checked which will work. In example 2 you use value=checked -- won't do what you want In example 1 you echo just checked (which will work but is deprecated) but have [ ] after the variable name making it an array and I suspect you don't process it as an array.

Still banging my head against a wall. I added a couple of alerts and I'm not making it to the second one even though the first shows %up% $(function() { $(".vote").click(function() { var id = $(this).attr("id"); var name = $(this).attr("name"); alert ('%'+name+'%'); var parent = $(this); if(name=='up') { var idtrim = id.replace('-up',''); var dataString = 'id='+ idtrim ; var oppid = idtrim + '-down'; var opposite = getElementbyid(oppid); $(this).fadeIn(200).html('<img src="dot.gif" align="absmiddle">'); alert (dataString); $.ajax({ type: "POST", url: "updown/up_vote.php", data: dataString, cache: false, success: function(html) { parent.html(html); } });

It may be my lack of ability to think straight because I have a cold and couldn't sleep but this makes no sense to me. I got an up/down voting script from here: http://www.9lessons.info/2009/08/vote-with-jquery-ajax-and-php.html I wanted to integrate it into a project that allows logged in users to vote. Each user gets one vote (up or down) per item being voted on but can change their vote. To do so I keep a table with user_id, item_id, up_vote (bool), and down_vote( bool). If a voter votes the yes or no that they voted for is incremented. If they later change their vote, the prior vote counter (up or down) is decremented and the new vote is incremented. A new vote that duplicates the users existing vote is ignored. Here's the client side code: $(function() { $(".vote").click(function() { var id = $(this).attr("id"); var name = $(this).attr("name"); var dataString = 'id='+ id ; var parent = $(this); if(name=='up') { $(this).fadeIn(200).html('<img src="dot.gif" align="absmiddle">'); $.ajax({ type: "POST", url: "updown/up_vote.php", data: dataString, cache: false, success: function(html) { parent.html(html); } }); } else { $(this).fadeIn(200).html('<img src="dot.gif" align="absmiddle">'); $.ajax({ type: "POST", url: "updown/down_vote.php", data: dataString, cache: false, success: function(html) { parent.html(html); } }); } return false; }); }); </script> I got that all to work, but the code that returns the up or down vote counter only returns the counter for the current vote (up or down) so I needed change the code server side to return two values in case the opposite vote was decremented and the client side code to display both. I changed the server side so that I get back data as json - for example now in my working Up_vote script I get: {"upvalue":"13","downvalue":"38"} instead of just a 13. So, now comes the hard part. I want to display 13 in the up box and 38 in the down box. I go to look at how to get the equivalent down box my up box and find that both boxes have the same id="1" (which is not legal) so I can't use getElementbyID one has name="up", the other name="down", but I can't use that because I have ids 2, 3, 4,... each with its own up and down. Both have the same class "vote". So, I decide to fix the non-unique IDs so I make the IDs 1 into 1-up and 1-down. Now, I need to trim the -up off before my AJAX call to up_vote and have my script know that 1-down is where it needs to put the down value. So I try this: $(function() { $(".vote").click(function() { var id = $(this).attr("id"); var name = $(this).attr("name"); var parent = $(this); if(name=='up') { var idtrim = id.replace('-up',''); var dataString = 'id='+ idtrim ; var oppid = idtrim + '-down'; var opposite = getElementbyid(oppid); $(this).fadeIn(200).html('<img src="dot.gif" align="absmiddle">'); $.ajax({ type: "POST", url: "updown/up_vote.php", data: dataString, cache: false, success: function(html) { parent.html(html); // opposite.html(html.down_votes) } }); alert (html); } else { var idtrim = id.replace('-down',''); var dataString = 'id='+ idtrim ; $(this).fadeIn(200).html('<img src="dot.gif" align="absmiddle">'); $.ajax({ type: "POST", url: "updown/down_vote.php", data: dataString, cache: false, success: function(html) { parent.html(html); } }); } return false; }); }); and I get nothing back. The alert (html) never shows. using alerts to debug dataString is: "id=1" oppid is: "1-down" I updated from jquery 1.2.6 to 1.8.1. I can run the server side script directly and it works. If I change the last lines of the server side code to just echo WOW it works in the first javascript but not the second. What obvious stupidity am I missing?

I found this on the php mail page. http://php.net/manual/en/function.mail.php

I'm guessing that you need to select a database or just failed to connect at all in connect.php. Documentation can be found here: http://php.net/manual/en/function.mysql-select-db.php