https://bugzilla.wikimedia.org/show_bug.cgi?id=9838
--- Comment #19 from Tyler Romeo <[email protected]> 2012-06-08 23:16:06 UTC --- (In reply to comment #18) > (In reply to comment #17) > > OK, so here's my suggestion. I like the SpecialPage idea, but I'm a little > > weary about relying on memcached so much, mainly in the case of > > installations > > where the wiki is configured not to have any type of object caching. > > We refer to it as memcached, but $wgMemc can be backed by other things, > including the DB. We could use a cache which defaults to CACHE_ANYTHING. Yeah, but it could also be CACHE_NONE. And $wgMainCacheType defaults to CACHE_NONE even though everything else is CACHE_ANYTHING. Furthermore, we have to keep in mind that memcached cannot be guaranteed, whereas a database entry is much more reliable. The result can still be cached in memcached, but why only do that when we can also store it in user_newtalk like talk page messages are (and on that note, why aren't talk page notifications stored in memcached also?). The solution I've been drafting would make user_newtalk a more general message storage table and enclose user messages in a UserMessage class, rather than cluttering User with five or so member functions. It would not increase request times because it would just become part of the same query for talk page messages. > > So here's my suggestion. Mediawiki already has a logging table... > > > > After any login (good or bad): > > Log the login. > > > > When logged in user browses any page: > > Show notification for bad logins (similar to new talk page > > message notification). > > > > After X bad logins in Y amount of time w/o user logging in: > > Email user. > > > > In this setup, the user is only emailed if they haven't logged in during the > > attacks, because with notifications there's no need to warn a user twice > > about > > the same thing. > > If it's not implemented as a SpecialPage or other separate action, they could > be missing the notification, while the wiki counts it as "shown". > We could add a button to the special page to clear the store and thus reset > the > sending of an email. It would be part of Special:Log, specifically Special:Log/auth. The messaging would function exactly like new talk page messages, meaning the message is only wiped when the user visits the log (or presses a clear button if we want). As a database entry, there would be no way they could miss the notification. > > Also, all login attempts are stored permanently in Special:Log, > > which means the user can look at his authentication records whenever he/she > > wants. Users will be restricted to viewing only their own auth logs unless > > they > > have a special permission to view all auth logs. Also, there would be wiki > > configuration variables that can enable/disable logging good logins, > > enable/disable this feature altogether, enable/disable notifications, and > > set > > the email intervals. > > WMF sites wouldn't want to permanently store the login attempts in the logs. > Even if you only stored the bad ones. Why not? The only problem I can foresee is the fact that IP addresses of login attempts would be logged, in which case we can just have an option to disable IP logging. At that point, all that is being logged is a message saying somebody failed to login to a certain account, and even then this information could only be obtained by the user whose account it is (or the government/hackers if a court order/security breach is involved). Overall, it is a much more theoretically reliable and secure idea to utilize MW's existing logging functionality to store authentication requests and their results rather then to cache them in memory pending the user's next visit. If a user doesn't log into Wikipedia for a week, and the threshold for email is also a week, then that memcached key is there for a whole seven days, which is generally not what memcached is used for (or at least not what I use it for). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
