Malfunction of some apps (in particular calendar, files_pdfviewer) triggered by notifications throwing TokenPasswordExpiredException #1827
Comments
|
Do you see the matching user in these logs in the original, or are they censored on the disk already: As far as I understand the password of the access token was marked invalid as it might have changed in the user backend: It should heal automatically after the user logged in via the web interface using the new password: It's a bit strange that no one complained about this for such a long time, so I assume some path changed somewhere recently. The only option I see is: clients need to be able to "get to know" this state and then need to ask the user to perform a login on the web view. |
|
Thanks a lot for your reply. The logs were copied from the EDIT: Oh, and yes, the Actually, problem A (the calendar problem) started after I switched to the I do not quite understand what you mean by:
I tried what I thought you were saying, i.e. logged in via Is there some other workaround I might try, like manually clearing expired tokens from some database table or cache? |
|
There is a You can run that for all of the users involved in the problem.
The problem is it has to be everyone involved in the action. So if multiple people would receive a notification from the same calendar change, all of them need to be okay (that part should be fixable). |
|
Thank you, that is a very helpful hint. Just tried that command with my NC instance A (user1 is me, user2 is the user to whom the calendar is shared): So, the first one is from 2019 … small wonder it has expired. Actually, I received the test notification in a browser, and after viewing it, I now get: So somehow, the expired tokens got renewed. How that happened, I have no idea (but you do, I guess …). Now for the other user: So, another token dating back to 2019 … If I understand you correctly, that user2 would now have to somehow refresh that token? I logged in as that user via OIDC – viewed the test notification, tried to dismiss it, got the error message "Notification cannot be dismissed"; then logged out, logged in via So now, the "Device token: 15680" seems to have been renewed, but the command still errors out. Anything I could do to fix that? Is there a way to delete the tokens from the Thanks for your time and help! |
|
Can you run the following query for that user: SELECT `id`, `password_invalid`, `last_activity`, `last_check`, `type`, `remember`, `name` FROM `oc_authtoken` WHERE `uid` = 'user2';PS "name" is just to get an indication whether it's from a client or browser. If it contains real names (iPhone of User2) feel free to censor it away. |
|
I found the "problem" why this comes up now 28+
but we catch So our catch no longer covers 27 and before
and we catched |
Sure! Here is the output: |
Looks like an easy fix then … 😉 Thank you! |
|
That being said, that would explain why some people loss their push hashes... if the password was temporarily invalid, we wiped the push token in 27 and before 🤔 |
|
Can you apply the following patch and then retry: diff --git a/lib/Push.php b/lib/Push.php
index cfbd70c0..43bcea39 100644
--- a/lib/Push.php
+++ b/lib/Push.php
@@ -28,13 +28,13 @@ namespace OCA\Notifications;
use GuzzleHttp\Exception\ClientException;
use GuzzleHttp\Exception\ServerException;
-use OC\Authentication\Exceptions\InvalidTokenException;
use OC\Authentication\Token\IProvider;
use OC\Security\IdentityProof\Key;
use OC\Security\IdentityProof\Manager;
use OCA\Notifications\AppInfo\Application;
use OCP\AppFramework\Http;
use OCP\AppFramework\Utility\ITimeFactory;
+use OCP\Authentication\Exceptions\InvalidTokenException;
use OCP\DB\QueryBuilder\IQueryBuilder;
use OCP\Http\Client\IClientService;
use OCP\ICache; |
|
YES! Both problems fixed. 🎉 |
|
As per commit message I'm not sure whether the behaviour is correct, but at least it's the same as on 27 again. |
|
From my point of view, everything looks fine. The affected user can also dismiss notifications again, which failed before. So, I'm going to close this now, hope that's ok. Again, thank you! |
|
Let's keep it open so it closes when the PR is merged |
On two different Nextcloud instances, I experience problems with the notifications app which manifest themselves as problems with other apps which are triggering notifications. I am filing this here because in both cases I observed, the problems go away when the
notificationsapp is disabled (or, in the case of the calendar app malfunctioning, theevent_update_notificationapp).Problem scenario A (calendar):
Steps to reproduce
calendar, thenotifications, and theevent_update_notificationapps.Expected behaviour
The data entry sidebar should close and the new appointment should be saved in the calendar.
Actual behaviour
The spinner displaying progress spins infinitely in the now empty data entry sidebar. When I refresh the page, the data entry sidebar is still open with the unsaved appointment.
Problem scenario B (files_pdfviewer):
Steps to reproduce
files_pdfviewerand thenotificationsappExpected behavior
The PDF file should be displayed in the PDF viewer app.
Actual behaviour
The sharing page opens, but the PDF viewer pane remains empty.
I can reproduce the
calendarproblem reliably on one of the two Nextcloud instances, but not on the other; thefiles_pdfviewerproblem on the other hand happens consistently on the latter instance, but cannot be reproduced on the former. Both instances run on the same server, in the same nginx + php8.2-fpm stack.A problem similar to scenario A has been reported as an issue against the calendar app:
Also, these two issues might be related, as they also involve
TokenPasswordExpiredExceptions:OC\Authentication\Exceptions\TokenPasswordExpiredExceptionspammed in log as "error" server#41408Server configuration (identical for both instances, unless otherwise specified)
Operating system: Linux 6.1.0-18-amd64 x86_64 (Debian trixie/sid)
Web server: nginx 1.24.0-2+b1
Database: mysql 10.11.6
PHP version: 8.2.7
Nextcloud version: Nextcloud Hub 7 (28.0.3 RC1)
Where did you install Nextcloud from: via the built-in updater (originally, from Github, ages ago)
Signing status:
List of activated apps:
For the instance from scenario A:
For the instance in scenario B:
Nextcloud configuration:
Instance from scenario A:
Instance from scenario B:
Are you using an external user-backend, if yes which one:
user_oidc, and also LDAP in the first instance.Client configuration
Browser: Any of Firefox (122.0.1), Brave
[Version 1.64.74 Chromium: 122.0.6261.43 (Offizieller Build) beta (64-Bit)](https://brave.com/latest/), Chromium Version121.0.6167.160 (Official Build) built on Debian trixie/sid, running on Debian trixie/sid (64-bit)Operating system:
Linux 6.6.15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04) x86_64 GNU/LinuxLogs
Nextcloud log (data/nextcloud.log)
Scenario A:
Scenario B:
Browser log
Scenario A (browser console log):
Scenario B (browser console log):
Thank you for looking into this. If it would have been better to file two separate issues, please advise me to do so. Also, if there is anything else I can do to help debug this, let me know.
The text was updated successfully, but these errors were encountered: