recording last_login on users should be optional
Opened this issue · 2 comments
Recording last_login happens on each login. On a large extranet/intranet it creates a lot of writes which can result in poor performance and conflicterrors. Knowing the last_login isn't always worth the problems this causes. The only current work around is to put in an alternative user storage which isn't well documented and requires additional infrastructure.
A plan to fix this would be
- new registry entry to toggle recording last_login
- (optional) extra field in user settings to control said toggle
- changes to https://github.com/plone/Products.PlonePAS/blob/master/src/Products/PlonePAS/tools/membership.py#L748 to impliment the toggle (and default to backwards compatible setting)
- search for any UI that interacts with last_login such as user search to see if it needs changing
- tests
- PR
That highlighted line does something which affects the result of the setLoginTimes method, which returns True if the user logs in for the first time, and False otherwise. IMO, this is the main use of that last_login_time information.
If it would be possible to opt out from storing this information entirely, we wouldn't have a way to know whether someone has ever logged in (for newly registered users, at least).
My main problem with this method is:
When the ZODB is mounted read-only, no logins are possible
(unless some external user storage is used, e.g. with pas.plugins.sqlalchemy). One might want to prevent user-triggered changes during some data conversion step in another client process, or in a site which is about to move away to another server and awaits the DNS information to be refreshed. In the case of our site, some people visit paid online courses, which works nicely regardless of the readonly state; but if they cannot login, they can't view their courses.
Thus, normally we need that last_login_time information only to distinguish first-timers from repeatedly logged-in users; but we do need it because we don't have an alternative ready, right?
Of course, logins should not fail for this reason.
If the visitor has logged in before, we might or might not inform her/him when the time could not be updated, and that no writing is currently possible (with a configurable information about the reason, perhaps). A warning or even info would be sufficient.
If the visitor has not logged in before, we have a more serious problem; things might need to be done for first-timers, and they can't be done (and be it for the sole reason we don't want to do them more than once). The login should succeed, but the user must be informed.
Problem: What should we return in this case?
but why do we need to update the date, it just have to be newer than the default value and we know it is not the first login.
Beside that, it seems not working for everybody anyway.
I have a Plone 5.1 where the dates should be the same but they are differ for an hour, probably time zone related.