How to remove/revoke Thousands of Device Session Lines from: Personal -> Security?

[eggithub]

Is there a way to do this? I have probably thousands of session lines in the database somewhere, of which only a mere 1000 are displayed from months back.

Is there perhaps a database query that I can use to clean this up. Which Tables? Are these settings even stored in the database?

The problem is that I cannot see the lines for the App Passwords that I added recently...

Thanx in advance

[MorrisJobke]

cc @ChristophWurst

Do you know by any chance where those are coming from? Are those app passwords (three dots at the end) or sessions?

[eggithub]

Well the strange thing is that these lines used to be in the sessions section. They do however have three dots at the end.

Running 12.0.2 btw...

See also screenshot

And see also issue #5083

[eggithub]

Might it be a good idea to make a "select all" button to mass revoke? This way I could deselect the ones added with app passwords. However if this is a bug then this is not needed but then the database should be fixed in the next upgrade I guess?

Also another thing to point out is that the app passwords seem to work now for this account (see #4535, which I closed). I learned this when I used OCC to enable TOTP and figured that the OCC command overrules the TOTP personal settings. I concluded that although the personal settings show "TOTP enabled", this is only true when OCC totp:enable is invoked. I vaguely rememeber playing with the OCC command unaware that I eventually turned it off using OCC. Can you confirm this behaviour?

Cheers!

[eggithub]

Check also this screenshot:

The 2 app passwords just added show up in the Security section. However, when I refresh, I see this:

so after a refresh only the oldest lines are shown...

[ChristophWurst]

Also another thing to point out is that the app passwords seem to work now for this account (see #4535, which I closed). I learned this when I used OCC to enable TOTP and figured that the OCC command overrules the TOTP personal settings. I concluded that although the personal settings show "TOTP enabled", this is only true when OCC totp:enable is invoked. I vaguely rememeber playing with the OCC command unaware that I eventually turned it off using OCC. Can you confirm this behaviour?

Exactly. The occ command allows admins to generally disable 2fa for a specific user. That means that even if the TOTP app thinks it is enabled, the user won't be prompted for the TOTP code. Once we have a combined settings page for 2fa apps we could add a notice on top to warn users when 2fa was disabled by an admin. Sorry if that caused confusion.

[eggithub]

I see enhancement and feature:settings added to this issue, but this is also actually an issue! Is there any intension of marking this issue as a bug? From the session log it is clear that I've had this issue over a year. Same goes for the issues I filed on App Passwords Vanishing which I'm still having (closed them, but need to reopen them or file new issues). I still think the extensive sessions list and the vanishing app passwords are connected...

My point is that although I filed a number of issues regading sessions and app passwords, not much has been attemped to pick these issues up. Am I supposed to fix these myself (which I surely can't)? Is there a lack of people or interest to look to these issues? I know it's an opensource project and yeah, I know I use it for free and it is a beautiful project. That is why I want to help by filing issues when I have some. But if hardly any of these issues I filed get resolved then what is the point?

I've asked numerous times if devs need any more input from my side, with hardly any response whatsoever. What can I do to help resolve these issues I have?

Cheer!

[ChristophWurst]

I know it's an opensource project and yeah, I know I use it for free and it is a beautiful project. That is why I want to help by filing issues when I have some. But if hardly any of these issues I filed get resolved then what is the point?

And I highly appreciate that. I've yet not been able to reproduce your issues. I sometimes see a high number of session tokens but they are cleaned up after a few hours. Hence I'll have to take another, deeper look at this and try to improve this behavior.

[eggithub]

Could someone add some sort of a "Revoke All" button (at least temporarily), so I can revoke all sessions at once? This way I can at least see what happens when I add new App Passwords. And this way the thousands of sessions are removed all at once and I can again check whether App Passwords keep dissapearing or not...

Cheers!

[eggithub]

I found another account on my nextcloud instance where you can clearly see that, although app passwords stick, the old sessions are also there. I find that it weird that Android Sync Apps and Dedktop Clients show only sessions of more than 8 months back. Perhaps 8 months ago some Session handling code changed?

log_personal_security.txt

[ChristophWurst]

@eggithub interesting finding. Do you have access to your DB? If so, please check your oc_jobs table and check whether you've got an entry for the DefaultTokenCleanupJob and if so, when it was run the last time. Maybe your cron jobs aren't configured properly.

On my dev instance this looks like this:

[eggithub]

Have to check DB after work but the admin setting is:

Should I go for Cron instead (and off course edit the cronjob for www-data)? And if I change that to Cron; how quickly will I see the result?

[ChristophWurst]

Should I go for Cron instead (and off course edit the cronjob for www-data)? And if I change that to Cron; how quickly will I see the result?

I think so. But that of course depends on your instance (e.g. size, users). As I'm neither an expert in this area, I recommend checking out https://docs.nextcloud.com/server/12/admin_manual/configuration_server/background_jobs_configuration.html :)

[eggithub]

Ok, so I changed to Cron and all old sessions have been removed, meaning sucess! Thanx! Could not check what you asked but I guess that "last time run" has probably changed to a more current time ;) Should this AJAX option be considered buggy with my instance? Otherwise this issue can be closed!

Now I will check if App Passwords stick for this user, which was my original issue ;-)

[ChristophWurst]

Awesome, great to hear it's working now :)

Should this AJAX option be considered buggy with my instance?

I assume your instance is too big for the very simple ajax cron. Hence it probably ran into a timeout and the php process was killed.

[zippytiff]

Hi,

Any progress on this, having hundreds of lines of devices sessions when a user only has 3 devices makes no sense.

And no way to tidy up

Help

ZT

[ChristophWurst]

@zippytiff that sounds like a bug. There shouldn't be hundreds of sessions. Please file a new bug report with your setup specifics. If you're not already using the latest version, I recommend upgrading first. Also make sure that you've configured your cron jobs correctly.