Update:  it does post to DB table but it does not stay there very long, it is on there seems like less than a few min at most. So how to fix this?

 So again this issue cost me 200 members on one site and over 100 members on another site that i purged, and im rather upset about it.

I will be eating alot of crow on this one trying to get those members back.  

Another UPDATE:  I set the expire time to 1 day and  this time i copied the code right out of the db and still gave me invalid code.  And did it last one day, nope in side of a couple of min or as soon as i attempted to use the code it was gone. 

Does this process delete the db table entry once an attempt is made?

No looks like the cron is clearing the table every couple of min in which i have to find and stop. it should not do that...  its not even paying attention to the timestamp i set one for next week and it still removed it.  

Any help would be appreciated.. Where does this remove the entries from the user_reset_password table?

I thought it might be the deleteExpiredEntities function but i dont think it is. 

i think i found it in the cron php file it was set for 10 i just changed it to 60 i will test.  which brings up the question why are we setting an expire timestamp on the row if the system will remove all entries in a matter of min when ever we set that.    the timestamp on the row means nothing in this case.

I think i have it fixed i will report what i did here shortly after some testing.

ok here is what i did

in the  ow_system_plugins/base/bol/user_service.php

find the function getNewResetPassword

 //changed to exp in 1hr
        $resetPassword->setExpirationTimeStamp(( time() + 3600));
                                                                                    // 1 hour

        // original code commented out
        // $resetPassword->setExpirationTimeStamp(( time() + 24 * 3600));

and then in ow_system_plugins/base/cron.php

$this->addJob('deleteExpiredPasswordResetCodes', 3600); // changed to 3600 = 1 hr, original value was 10 which i believe was 10 sec not minutes.

And now it works..

Daisy can you confirm this for me please thanks... :)  but i just tested and it does work.  But just please confirm that the attribute for that is in sec not minutes.. 

 thanks. :) 

thanks funny i did a search for awhile to find what i needed and none of those came up.  But your link was the beginning of a trail from one link to the next that led me to here

http://www.oxwall.org/forum/topic/2495

which is the only one that really addressed the issue at all and but sadly only half the issue.

The real issue is the cron, regardless what you set the expire timestamp to the cron will delete them all when it is run.  Example during my testing i set up a dummy record thru the insert option in the db to expire next friday.  And guess what, when the cron ran it was gone.

So that is why in my instructions it says to change both, the service php and also the cron php as well.  If you dont your just chasing your tail.

This is another value that should be set dynamically either thru the config file as a define or from the admin area in settings allowing us to choose how long we would like them to last.

>>in the  ow_system_plugins/base/bol/user_service.php

Thanks :)

I had the same problem here is what I did to correct it.

ow_system_plugins/base/bol/user_reset_password_dao.php

At line 104

$example->andFieldGreaterThan(self::EXPIRATION_TS, time());

to this

$example->andFieldGreaterThan(self::EXPIRATION_TS, time() + 3600);

3600 = 1hr

The easiest way to solve this issue is to go to your phpmyadmin and edit the following table:

ow_base_cron_job

The value that needs to be edited is 

 BASE_Cron::deleteExpiredPasswordResetCodes

Set this value to 1225115 or whatever you desire, this value is the time in seconds that the code needs to be remembered