Module: Process Login History

[teppo]

This module -- actually pair of modules -- keeps track of login attempts to your site, both successful and unsuccessful. The point of this is to give you better understanding about users' activity and environments they use and favor; browsers, browser features such as Flash and Javascript, devices, screen and window sizes. Based on my experience it could also prove out to be rather helpful when debugging error reports by users.

Since most of this module was written during one weekend (short time for someone like me who way too often gets stuck trying to make meaningless little details "perfect") I'm very much aware that there are still quirks and even missing features I'd consider "very important." If anyone finds this module interesting enough to give it a try, any and all ideas, comments and problem reports would be very much appreciated!

http://modules.proce...-login-history/

https://github.com/t...essLoginHistory

How does it work?

Process Login History itself is pretty simple and focuses on showing logged data. Probably only thing worth mentioning is that user agent strings are saved to database in their original format and converted here run-time into human readable values. Currently this is done with a private function that tries to identify most common platforms, device types and browsers, but I've planned to add support to either phpbrowscap and/or PHP's native get_browser().

Login tracking is achieved by hooking after Session::login and ProcessLogin::buildLoginForm, though latter is only used to add some extra fields to login form in order to collect slightly more information about user agent. Hooks are added by separate autoload module Process Login History Hooks to avoid loading unnecessary stuff all the time.

I'm not sure if this naming convention is correct though.. it's not a process module but still very much related to one -- ideas, anyone?

How do you use it?

When installed this module adds new database table (process_login_history) for storing data and new page called Login History under Admin > Setup. What this page should look after couple of logins / login attempts is visible in the screenshot below. For more information and some ideas I've planned for later revisions, see README.md.

[ryan]

Great module Teppo! Love the output and the whole idea of having this log. I will definitely keep this one installed and look forward to using it. I also like all the details you thought of, like automatic pruning of logs with LazyCron, and keeping track of non-existent users. Very nicely put together. The only thing I might like in some future version is the IP address for each login, just to help for those times when something looks suspicious. Thanks for your work in putting together this module.

[teppo]

Thanks Ryan

IP logging was intentionally left out to avoid collecting too much "identifying" data, but right now I'm thinking of adding it anyway -- it shouldn't come as a surprise to anyone that this can (and will) be logged, not to mention that Apache already keeps track of this information. This was also suggested when I asked a coworker for comments earlier today.

[apeisa]

Great work Teppo, will test this soon. Based on the login times on the screenshot, this required some late night coding also

BTW: Your link to modules directory is for edit view: http://modules.processwire.com/edit/process-login-history

[teppo]

Thanks Antti - link fixed

[apeisa]

Almost fixed, we are getting there (it's 404 now, missing /modules/ before module name)

[teppo]

... yeah, that's what you get for changing things while on mobile. Now it should be fixed

[Martijn Geerts]

Good work Teppo ! Sometimes when we ask customers to tell what browser they're using for the admin, the respond with "windows"

Thank you for making this module !

[muzzer]

Great stuff Teppo, very useful.

A minor thing, the java-script field is not showing correct for me though, see attached image.

I'm wondering if it's possible to track not only logins but also some editor actions - say log each time a page is edited. I use this logging feature a lot when I use modX as I can see if clients have edited a page in the last hour or so - It allows me to download the latest database to my dev machine, make some changes and then reupload (overwrite) knowing I'm not overwriting any new client edits.

Anyway, thanks for a cool mod

[apeisa]

For that purpose you could use $pages->find("sort=-modified, limit=5"). But I do think that would be nice addition or a great separate module.

[teppo]

First of all, thanks @muzzer. It's nice to hear that someone likes and uses this module

About JS showing up as disabled, I'm not really sure why that's happening. Based on your screenshot it seems to be a problem concerning multiple browsers, which makes it even more strange. I'm guessing those are both logged from one computer? In that case this problem could occur either client or server side, which makes finding it's source somewhat complicated.

Anyway, to sort this out it would be really helpful if you could post here (or PM me) one or more rows from your process_login_history database table (ones related to login history rows with JS seemingly disabled) so I could at least decipher this problem is in hooks module or the login history module itself. You might also find something interesting related to this at your Apache error logs. This could, for an example, be somehow related to JSON encoding - in which case the problem should show up at both the db table and Apache error log.

This is exactly what I hate about remote debugging: it's alll fun and games when you've got access to a system where the problem occurs, but mostly guesswork when that's not the case..

Logging page edits, as important as that is, isn't really part of what this module is intended for. You could always do something similar to what Antti suggested above to achieve this, but a more sophisticated solution would require another module. As it happens, I do actually have something like that planned, but that's another story entirely.

Edit: I pushed a new version of this module to Github an hour ago. You might want to give that one a try too - it did fix a minor JS quirk but that shouldn't really be the cause of the problem you've mentioned here..

Edited December 22, 2012 by teppo

[antknight]

Teppo, first if all, thanks for this super module!

Just wondering about the login times. In my installation they show the server time (in Amsterdam). So in the UK, currently on GMT time, it shows GMT+1. Is there a way to correct this?

I have set timezone to $config->timezone = 'Europe/London'; in config.php if that has anything to do with it?

[teppo]

@antknight, thanks for your kind words and sorry for taking so long to reply!

What you're describing sounds strange, since (unless I'm misunderstanding something) while database contains timestamps in server time, PHP should output them with the timezone you've defined. This happens because class ProcessWire (/wire/core/ProcessWire.php) sets ini variable date.timezone to whatever value is found from config.

Just to make sure that everything is configured correctly, if you put following lines somewhere within your site what's the output?

if (date_default_timezone_get()) echo 'date_default_timezone_set: ' . date_default_timezone_get() . '<br />';
if (ini_get('date.timezone')) echo 'date.timezone: ' . ini_get('date.timezone');

[antknight]

Output is as follows:

date_default_timezone_set: Europe/London
date.timezone: Europe/London

[Soma]

Maybe the server time setting is wrong?

[antknight]

I did think that so I tried this:

$time = $_SERVER['REQUEST_TIME'];
print date('Y-m-d H:i:s', $time);

Is that correct? If so it returned the correct time.

[Frank Vèssia]

Great module, I started using it and found a little bug in pagination, see the attachment

[teppo]

@Sevarf2: thanks -- pager problem is now fixed, just pushed version 1.0.2 to GitHub

[lpa]

Hi Teppo,

Are you planning on adding the IP number logging some day soon? And maybe os version?

[teppo]

@lpa: IP address logging is added now. Grab latest version from GitHub and you should see new "Log IP addresses" option in module settings for Process Login History Hooks.

This isn't enabled by default to avoid some possible (though probably quite theoretical) legal issues. I know that most servers already gather IP addresses of visitors, but one might argue that being bundled with other data that this module collects makes those more likely to be considered "personal information", which in turn may require additional statements on the site itself etc.

Edit: forgot to mention that I'm still wondering if collecting OS version is really useful. If you (or someone else reading this) can provide me with some examples where that data would be useful I'm all ears

Edited January 4, 2014 by teppo

[cstevensjr]

For me, knowing the OS, Browser, IP address and other typical client-side information makes troubleshooting issues with my clients a whole lot easier.

I myself currently don't use any Microsoft Windows products, however I am a long time MCSE and routinely provide support for that platform.  Each MS Windows version has it's unique qualities and feature set.  For me, knowing what the OS is, gives me a leg up on fixing whatever is wrong.  It's really the first thing I ask any client when doing technical support.

BTW, the Process Login History module is fantastic and very useful.  Thanks for making it available.

- Charles

[lpa]

Thanks Teppo!

I think when having the platform, why not the os version too? If you for example want to help solve some problems your users might have with your site, it might help to know which browser on what os they are using without asking.

The new version doesn't show up in Modules Manager. 

Edited January 4, 2014 by lpa

[teppo]

@lpa: I was under impression that modules directory was able to get version directly from GitHub, no idea where I got such an idea.. anyway, module version is now updated and modules manager should probably see it too

These days most platform-related issues (that I'm aware of) have been between OSX and Windows, Windows and Linux, Android and iOS and so on.. not so much between different versions of same platform. Generally speaking IE8 has same issues whether installed on Vista, Win7 etc. This is why I didn't feel that OS version would really matter.

The module is already collecting UA strings, which can be used to identify not only platform but also it's version. It' a bit tricky, though, but I'll look into adding this feature.

PS. "Please note that the inflight internet is only available when the plane is above 10,000 feet." I did *not* know that wifi could work this good on a plane.. miracles of modern (at least to me) technology, I guess

[ryan]

lpa: I was under impression that modules directory was able to get version directly from GitHub, no idea where I got such an idea.. anyway, module version is now updated and modules manager should probably see it too 

It does grab the version automatically, though only once per day (and it caches it). So it may take up to a day at the most in order to display the updated version number.

[teppo]

Thanks, Ryan -- looks like we were too impatient