@amercader , can we use successful login signal from the UsernamePasswordAuthenicator here? Or, if doing it inside login-view is better, maybe successful login signal also should be moved there

@TomeCirun @smotornyuk as I mentioned on the issue I think that rather than tracking logins we should track the last time a user has been active, ie identified in a request. Otherwise we lose all API access. So basically have a last_active field instead of last_login and hook it to identify_user.

This does mean a DB write on each request so maybe we can store the current last_active value in the session and only write it if its bigger than X mins (which can be configurable).

If all this seems to complicated and we want to stick with actual UI logins I'm fine with it.
But then @smotornyuk the signal you suggest would probably miss logins from alternative authentication methods like SAML2, OAuth etc right?

signal you suggest would probably miss logins from alternative authentication methods

Yes, that's right. When I added this signal, it decided that Authenticator is the right place to notify about successful logins. And other authenticators probably should also emit this signal when it's appropriate. I didn't put this signal to the logged_in view, because it cannot see the difference in cases when the user just signed in, and when it already has an active session and just visited /user/logged_in URL accidentally.

current last_active value in the session and only write it if its bigger than X mins

This means that we have to collect all the sessions periodically and check them. Which in turn requires two decisions:

• should we use Redis instead of sessions? It is fast, much more straightforward in terms of iterations over records, and even allows us to build some sort of admin page with an activity table for users, with a button "FlushIntoDB" (just as an example, do not consider it seriously). The obvious problem is a data loss when Redis reloaded.
• should we use background jobs/cron jobs with CLI command / other triggers that will write data to the database?

Another option(really unreliable) is to modify the user object and do not call Session.commit. Eventually, some other action (update/create/follow/etc.) will commit the session and our changes will be stored. But there are some serious problems here:

• session rollbacks will erase uncommitted changes
• If there will be no writes for quite a long period of time, we can aggregate thousands of pending changes. It can slow down the following commit.

Hey, @amercader do these changes seem sensible?
And please if you could tell me why the test fails?

@amercader do you have any idea why this happens?
Thanks

@TomeCirun I don't know about these failures, but they are unrelated to your changes. I've created an issue to track them if you want to investigate in a separate PR: #6537

Thanks for your PR, we'll review it as soon as we have availability

Hey, @amercader is there anything else that can be done in this PR?
Thanks

@amercader is there anything preventing us to merge this PR?

is there anything preventing us to merge this PR?

Only time, and the relentless onslaught of the world against our attention.

Thanks for this, it's a very valuable contribution