I received a warning about several failed attempts to log into the account. Standard CheckUser did not provide information about this. When checking a suspicious IP address, the information came up for me. This means that the information about attempts is saved. For the benefit of hacking attempts on sensitive accounts, it is useful to program the interface to save the logs of the login attempts also when retrieving data on the target account and not only when retrieving data on the IP address. Thanks,
Description
Description
Event Timeline
Comment Actions
As I read it this is a feature request for CheckUser and does not concern LoginNotify. Please re-add the tag if I'm wrong!
Comment Actions
Yup. This would be a patch to CheckUser. This may be best done after the action is stored in a structured way as I suspect it may be best to allow the user to say if they want to see failed login attempts when checking an account.
Comment Actions
@dagesh.chazak: Thanks for reporting this. For future reference, please use the feature request form (linked from the top of the task creation page) to create feature requests, and fill in the sections in the template. Thanks!
Comment Actions
The methods to achieve this are:
- Implement the structured data change (T145265) in such a way that allows a SQL query to perform a search for just password resets on a particular account, so that the query can include these password resets.
- Add a new column to the DB that allows CheckUser to store what other results the row should appear in. This would likely involve this storing the user ID(s) of users that the row should appear in.
All solutions to this problem will require a change to the DB. The latter will be simpler but would require adding a new column which again will take time.
Comment Actions
Due to a recent socking case discussed on the checkuser-l list the need for this has been shown as evident.
Comment Actions
Because I've been asked to keep DB changes to a slow pace, this is likely not going to be implementable for a while. Ideally the structured data change for log events would be used to achieve this. Having an extra column to indicate which user IDs the results need to be in would then be made largely redundant once the parameters of the log event can be accessed like in the logging table.