Add device detection/ID provided by modules: fingerprintjs2

Ben and I talked about this a bit and are thinking that it could make sense to make login_history a bit more extensible. Here's what I plan to work on.

Currently, login history records time, IP address, the nature of the login (one time or regular) and the full user agent. My interest in the module is that it helps both users and admins of a site determine if a login is legitimate. Additional code might send an email to a user if they log in from a new device or if a login happens 5 minutes after the last one but is from an IP address on the opposite side of the globe.

For those purposes it is useful to know if a browser user agent has changed, but it's also useful to know more generally chrome and not necessarily "Chrome/53.0.2785.143 Safari/537.36".

So...this module could:

• invoke a hook on login to get data, e.g. letting other modules do detection (e.g. one that adds fingerprintjs2, one like browscap that detects browsers more generally)
• store a hash of that data in the login_history table along with a login_id primary key that is an incrementing integer serial
• set a cookie value in the browser with that hash
• invoke another hook with the hash, the login_hostiry.login_id primary key, all that data, so that:
  1. a module could detect if this current login is likely from the same device or a new one
  2. the modules can store their data with the login_id

I think it makes sense for fingerprintjs2 to be a submodule (e.g. login_history_fingerprintjs2).

Eh?

I was thinking more about the cookie that is sent to the client. The default hash from the module is just user agent and ip address, so any site visitor can calculate a value and send it. This defeats one of the use-cases of this feature (i.e. detection of a login from a device that doesn't belong to the user logging in).

So...the cookied needs to be authenticated with an HMAC. I also filed #2822732: Add a serial primary key, a hash of data as device_id to teh table, send hash as a coooookie to cover just the parts inside login_history.module for this.

This patch is based on #2822732: Add a serial primary key, a hash of data as device_id to teh table, send hash as a coooookie and therefore will fail automated testing so I'm leaving as "needs work" but I basically consider this to be "needs review".

I felt like this should be a sub-module with its own schema, mostly because it records a lot more information about users.

I don't think browscap makes sense at this point, so removing it.

And this should now apply and pass tests.

This is just some small cleanups.

* Capitalizing Login History.
* Adding $account param to the hook for consistency.
* Adding dependency to the info file.

Sure, I can see making it optional. It does seem useful to me to store it in general. I can see an upcoming feature to limit the amount of data that gets fingerprinted (e.g. the canvas item is pretty huge and I'm not sure if it's valuable as a distinguishing point or not).

I agree with @greggles, it wouldn't hurt to offer the option to save the JS lib data but I think it would be useful to store it in general. Maybe we can store the data by default and offer the option to opt out of storing the data or limit the amount of data that is stored.

Also, should we minimize the JS and maybe create fingerprint2.min.js and lhfingerprintjs2.min.js files?

OK, recording the data is now optional and defaults to on.

And using the min js file from the upstream source.

OK, committed, so on to 8.x.

I am trying to install this patch on drupal 8 using
"composer require drupal/login_history:1.x-dev" but I do not see fingerprint data in login history report.

Do I have to install the patch separately ? Thank you

For Drupal 7 there is a sub-module that provides this feature since it is a bit different from the main module, so you do need to add it separately.

Thanks for the reply, I downloaded the D7 version and I get it now... will have to study how to adapt the sub module to drupal 8, hopefully it won't be too difficult.

@krem

hello, I would be interested to know where you got with this module?

Do you have any plans to port this to the latest version of the module?