kbking Posted October 8, 2010 Share Posted October 8, 2010 Thanks for this new approach to increased security! I like this add-on because yet another layer of security can not be wrong. It's just that it works too well. The 'New Customer' and 'Returning Customer' dialogue is disabled forever as it seems. One minute is constantly added to the waiting time, no matter how long I wait. I have also used the login.php that came with the contribution, but the result is the same. The contribution is here. So if someone knows how to tweak it or some good advise, I would appreciate it! Quote Link to comment Share on other sites More sharing options...
TheKnight Posted October 10, 2010 Share Posted October 10, 2010 Hello kbking, I need more information of your problem. Do you use 'login.php' or 'login_4_purchase_without_account_2.1.php'? First, please check your database: 1. Is the new table 'anti_hacker_login' added? 2. Check the rows of the table. The field `dt` contains the current TIMESTAMP, `fail` is the counter of the failed logins and 'process' must be empty or 'false'. I suppose the field 'process' contains the value true or 1. 3. Please delete the database rows or change the stored IP values to a value that is not yours. 4. Go to your shop and click the 'My Account' link. Is a new row containing your IP and your osCid added to the table? The field `dt` should contain the current TIMESTAMP, `fail` should be 1 and 'process' must be empty or 'false'. Please report the values of the latest row. Afterwards I will try to reproduce the problem. Quote Link to comment Share on other sites More sharing options...
kbking Posted October 11, 2010 Author Share Posted October 11, 2010 Hello kbking, I need more information of your problem. Do you use 'login.php' or 'login_4_purchase_without_account_2.1.php'? First, please check your database: 1. Is the new table 'anti_hacker_login' added? 2. Check the rows of the table. The field `dt` contains the current TIMESTAMP, `fail` is the counter of the failed logins and 'process' must be empty or 'false'. I suppose the field 'process' contains the value true or 1. 3. Please delete the database rows or change the stored IP values to a value that is not yours. 4. Go to your shop and click the 'My Account' link. Is a new row containing your IP and your osCid added to the table? The field `dt` should contain the current TIMESTAMP, `fail` should be 1 and 'process' must be empty or 'false'. Please report the values of the latest row. Afterwards I will try to reproduce the problem. Thanks for answering my questions! Here is the table 'anti_hacker_login' added to the database. And here how it looks like after I have clicked my Login-button. Quote Link to comment Share on other sites More sharing options...
TheKnight Posted October 11, 2010 Share Posted October 11, 2010 Hello kbking, your table seems to be ok. After entering the third wrong password the value 'fail' should be '4' and 'process' should be '1' (or true). I've done some tests, but I cannot reproduce your problem. Following a more detailed description to clarify how it works: The 'New Customer' and 'Returning Customer' dialogue is disabled when fail>3 AND process==true AND the login button was pressed. Please note, the 'New Customer' and 'Returning Customer' dialogue is always disabled when this condition is met. If in this state, the browsers 'reload' button is pressed, the wrong password is send again to the server. The result is that the 'New Customer' and 'Returning Customer' dialogue disabled again, 'fail' is increased and the dialogue-disable-time is increased by one minute. The dialogue will reappear when you wait one minute and then click on the 'My Account' (mitt konto) link or type in the browser address field: https://<your domain>/catalog/account.php?osCsid=<your session ID> For debugging please search the following line in login.php (line no. 50): $timediff = intval(($endtime-$starttime)/60); // $timediff in minutes Please insert following line afterwards: echo "endtime:".$endtime.", starttime:".$starttime.", timediff:".$timediff.", fail:".$included_code['fail']."<br>"; Please report the output and please describe more detailed how the problem appears (what link you used? how long you wait? and so on). Thanks for your assistance. Quote Link to comment Share on other sites More sharing options...
kbking Posted October 13, 2010 Author Share Posted October 13, 2010 Hi again I have followed (I hope) the steps outlined in 'Testing if Anti Hacker Login works', and I have put together images from the front end and from phpMyadmin. I guess You can see from the timestamps if I have done anything wrong. I have used the catalog/login.php from Your package (not my own). Also I have clicked only the My Account-button. Quote Link to comment Share on other sites More sharing options...
TheKnight Posted October 14, 2010 Share Posted October 14, 2010 Hi kbking, thanks a lot for your detailed post. It's very helpful. The problem is the negativ value of 'timediff'. Your 'starttime' is greater than the 'endtime'. When fetching the row from the database, the value of 'dt' is updated and the current time is stored in 'starttime', I suppose. This behaviour is different from my test system as well as from my hosted web- and database servers. Unfortunately I am not a mysql specialist. But take a look onto 'dt' attribute 'on update CURRENT_TIMESTAMP'. Please delete this attribute. My login.php script updates the timestamp when necessary, using the function 'now()'. The timestamp 'dt' may not be updated when reading the database. I'm looking forward to your hopefully positive answer concerning this problem. TheKnight Quote Link to comment Share on other sites More sharing options...
kbking Posted October 14, 2010 Author Share Posted October 14, 2010 Hi kbking, thanks a lot for your detailed post. It's very helpful. The problem is the negativ value of 'timediff'. Your 'starttime' is greater than the 'endtime'. When fetching the row from the database, the value of 'dt' is updated and the current time is stored in 'starttime', I suppose. This behaviour is different from my test system as well as from my hosted web- and database servers. Unfortunately I am not a mysql specialist. But take a look onto 'dt' attribute 'on update CURRENT_TIMESTAMP'. Please delete this attribute. My login.php script updates the timestamp when necessary, using the function 'now()'. The timestamp 'dt' may not be updated when reading the database. I'm looking forward to your hopefully positive answer concerning this problem. TheKnight Thank you! Now I deleted the attribute 'on update CURRENT_TIMESTAMP' and as it seems it solved the problem. I will take a closer look sometime tomorrow, for now, I very much thank you for your time and effort! Quote Link to comment Share on other sites More sharing options...
TheKnight Posted October 14, 2010 Share Posted October 14, 2010 Thank you! Now I deleted the attribute 'on update CURRENT_TIMESTAMP' and as it seems it solved the problem. I will take a closer look sometime tomorrow, for now, I very much thank you for your time and effort! You are welcome. It's my contribution and I would like to develop good quality. A good product that can be used by anyone. In the next days I will read the MySQL manual concerning the TIMESTAMP data type. Please give me a feedback, whether the problem is really solved. Thanks in advance. Quote Link to comment Share on other sites More sharing options...
tedbooks Posted October 21, 2010 Share Posted October 21, 2010 (edited) i have three different login pages on my site. so i just wanted to upgrade to 1.1 manually. i used a diff program to see the changes. the problem is that after the third false login it does not reset and show the login fields after 3 minutes. i noticed process column in the db gets empty. also i noticed that fail column starts at 2 for the first failed login. Edited October 21, 2010 by tedbooks Quote Link to comment Share on other sites More sharing options...
guavatone Posted October 21, 2010 Share Posted October 21, 2010 I tried v 1.01 and got this error after trying to do a legit login: debug endtime:1287694103, starttime:1287694090, timediff:0, fail:1 Warning: Cannot modify header information - headers already sent by (output started at /home/chuck70/public_html/diy-store/catalog/includes/languages/english/login.php:37) in /home/chuck70/public_html/diy-store/catalog/includes/functions/general.php on line 33 I didn't test with incorrect pw. after clicking on account, the top of page shows: debug endtime:1287694311, starttime:1287694090, timediff:3, fail:1 After the error I can go pack and look at my account though. It would be great if this worked. Thanks for the attempt to make this happen. Quote Link to comment Share on other sites More sharing options...
TheKnight Posted October 25, 2010 Share Posted October 25, 2010 I tried v 1.01 and got this error after trying to do a legit login: debug endtime:1287694103, starttime:1287694090, timediff:0, fail:1 Warning: Cannot modify header information - headers already sent by (output started at /home/chuck70/public_html/diy-store/catalog/includes/languages/english/login.php:37) in /home/chuck70/public_html/diy-store/catalog/includes/functions/general.php on line 33 Hi guavatone, it's my mistake. I know this error message. Please open file /catalog/login.php an go to line 52. The command: echo "debug endtime:".$endtime.", starttime:".$starttime.", timediff:".$timediff.", fail:".$included_code['fail']."<br>"; is for debug output only. This line outputs the message: 'debug endtime:1287694103, starttime:1287694090, timediff:0, fail:1' Delete line 52 (echo "debug .... <br>"; ) and the login script will work. Today I've released a updated login.php (version 1.0.2). kind regards TheKnight Quote Link to comment Share on other sites More sharing options...
TheKnight Posted October 25, 2010 Share Posted October 25, 2010 i have three different login pages on my site. so i just wanted to upgrade to 1.1 manually. i used a diff program to see the changes. the problem is that after the third false login it does not reset and show the login fields after 3 minutes. i noticed process column in the db gets empty. also i noticed that fail column starts at 2 for the first failed login. Hi tedbooks, the first call of login page sets the 'fail' column to 1. So your notice is correct: 'fail' column starts at 2 for the first failed login. The 'process' column in the db must be set to NULL, not empty. - The database column 'process' is defined 'process varchar(6) DEFAULT NULL'. - The login.php script updates the column with NULL: tep_db_query("update `anti_hacker_login` set `process` = NULL WHERE ahl_id='" .$included_code['ahl_id'] . "'"); - Afterwards the login.php script tests the column to NULL: $ahl_process = (is_null($ahl_array['process']) ? false : true); Please check the database 'process' column if it contains a NULL. kind regards TheKnight Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.