We have recently noticed some odd behaviour with the ASP.Net membership system.
When a user is locked out, as a result of incorrect password entry, the last lock out property (In the DB - aspnet_Membership.LastLockOutDate) is set to the time they were locked out, i.e. Time of the failed log in that caused the lock out, in our case the
3rd consecutive failed login in a 30 min period.
All well and good...until you unlock the user, at which point the last lock out property is reset to its default value - 1754-01-01 00:00:00.000
This of course is useless for the purpose of checking the time a user was locked out after they have been reset.
Could be of course there is a very good reason for this that I am missing...would appreciate any ideas/explaination as to this behaviour.
We have for now changed the stored procedure for unlocking a user to not update aspnet_Membership.LastLockOutDate.
Thank you.
membership
-
Please remember to click 'Answer' on the post that helped you. This ensures the people helping you out get the recognition they deserve, which helps the community at large!
Your implementation of this method should set the IsLockedOut property to false,
set the LastLockoutDate property to the current date, and reset any counters that you use to track the number of failed
log in attempts and so forth.
I checked, and the UnlockUser stored procedure does reset the date to the default 1754. So it's unintended, possibly a bug. You can, of course, just change it.
Darrell Norton, MVP
Darrell Norton's Blog Please click "Mark as Answer" if this helped you.
Marked as answer by SimonHarris on Feb 03, 2012 12:30 PM
Thank you for your post - This does indeed sound like a bug, supported by your find that the documentation does not match the behaviour.
We are using .Net 2, I wonder if this has been resolved in .Net 3.5 / 4?
Should this be raised as a bug with MS?
-
Please remember to click 'Answer' on the post that helped you. This ensures the people helping you out get the recognition they deserve, which helps the community at large!
SimonHarris
Member
58 Points
40 Posts
Membership - aspnet_Membership.LastLockOutDate
Feb 03, 2012 09:38 AM|LINK
Hi,
We have recently noticed some odd behaviour with the ASP.Net membership system.
When a user is locked out, as a result of incorrect password entry, the last lock out property (In the DB - aspnet_Membership.LastLockOutDate) is set to the time they were locked out, i.e. Time of the failed log in that caused the lock out, in our case the 3rd consecutive failed login in a 30 min period.
All well and good...until you unlock the user, at which point the last lock out property is reset to its default value - 1754-01-01 00:00:00.000
This of course is useless for the purpose of checking the time a user was locked out after they have been reset.
Could be of course there is a very good reason for this that I am missing...would appreciate any ideas/explaination as to this behaviour.
We have for now changed the stored procedure for unlocking a user to not update aspnet_Membership.LastLockOutDate.
Thank you.
membership
Please remember to click 'Answer' on the post that helped you. This ensures the people helping you out get the recognition they deserve, which helps the community at large!
DarrellNorto...
All-Star
86685 Points
9634 Posts
Moderator
MVP
Re: Membership - aspnet_Membership.LastLockOutDate
Feb 03, 2012 10:18 AM|LINK
Funny, the MSDN documentation on UnlockUser says:
Your implementation of this method should set the IsLockedOut property to false, set the LastLockoutDate property to the current date, and reset any counters that you use to track the number of failed log in attempts and so forth.
I checked, and the UnlockUser stored procedure does reset the date to the default 1754. So it's unintended, possibly a bug. You can, of course, just change it.
Darrell Norton's Blog
Please click "Mark as Answer" if this helped you.
SimonHarris
Member
58 Points
40 Posts
Re: Membership - aspnet_Membership.LastLockOutDate
Feb 03, 2012 12:31 PM|LINK
Thank you for your post - This does indeed sound like a bug, supported by your find that the documentation does not match the behaviour.
We are using .Net 2, I wonder if this has been resolved in .Net 3.5 / 4?
Should this be raised as a bug with MS?
Please remember to click 'Answer' on the post that helped you. This ensures the people helping you out get the recognition they deserve, which helps the community at large!