Time track depending on cron is not accurate
ilo - June 23, 2009 - 14:14
| Project: | Login Security |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | ilo |
| Status: | closed |
Description
In fact, currently, tracked events are only deleted on cron run and on hook_user.
The patch will delete old entries on every form submission (prior to being consulted). I've included the delete code in the login_security_validate function
| Attachment | Size |
|---|---|
| login_security_time_track_fix.patch | 1.09 KB |
#1
Should this be abstracted out as a function rather than repeated over and over again?
#2
I guess you are right. Should I also consider the other DELETE queries to be abstracted? or will they wait for the 2.0..
#3
I think the others ought to be, too.
#4
mmm.. several changes..
1st - Renamed function to support remove or expire tracked events with args, to be called here and there.
2nd - Default track time now is 1. This took me crazy for half an hour.. tests were working just because the DELETE part was not working at all, and having a default track time 0 it is imposible to have more than one event tracked: all events will be deleted the next submission.
3rd - I've also moved the place where the event is stored in the database. Before this fix, the event was stored after the user logs in, therefore, a valid login and a logout would leave a mark in the tracking table, instead of a clean table.
4th - Only clean tracked events on hoo_user 'update' if it's not being blocked, to keep the soft-blocking count still working.
5th - and last, I ve fixed in this patch also a minor issue for #495226: Login attempts message inconsistent, to remove messages like this: "you have used 4 of 2 attempts..".
In the .test file I just initialized the tracking time to 1.
It looks pretty stable for me now, I've tested by hand and verified the .test cases.
#5
arfm.. Sorry, that was not the final patch. This one is. In the previous one I forgot to include the change in default track time value and change a test to verify messages are showing correctly.
This one gives: Overall results: 252 passes, 0 fails, and 0 exceptions
#6
Even worse, forget the #4 and #5 patches, this is the good one. This is the reason why I hate to touch anything such late as now..
#7
#6 looks ok, with the exception that I'm not a fan of restricting features turning themselves on by default without an admin knowing about it (i.e. the time tracking).
#8
Having time tracking window being 0 in the beginning will avoid events to be kept in the database since the installation, and being set to 1 hour, would ensure the last hour events are kept in case of an admin needing to activate any of the protections urgently.
On the other hand, no feature is set to on in this case, because all protections still remain deactivated, so no check/change is performed.
In any case we can put to 0 again, because tests now set this value from the begining.
Deekayen, will you be able to review it? or may I do other commits and reroll this one later?
#9
do your commits
#10
499788_login_security_time_tracking_fix_4.patch no longer applies cleanly
#11
mm it's working for me.
- Verified as:
removing old folder
downloading a new "6-dev branch" copy
applying the patch
If you give more information I could try to see where are the changes, so you don't have to review the patch, or I could commit and go on.
#12
Commited to DRUPAL-6--1
#13
Automatically closed -- issue fixed for 2 weeks with no activity.