Yes I too had the same token but that was with Firefox. My normal browser is Safari.
Dj
So I found the wallabg2 log. It is in /var/www/wallabag2/var/logs/. I don’t know if it helps but here is one login attempt:
[2024-09-17 15:13:13] app.ERROR: Authentication failure for user "#####", from IP "#######", with UA: "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36". [] []
[2024-09-17 15:13:13] security.INFO: Authentication request failed. {"exception":"[object] (Symfony\\Component\\Security\\Core\\Exception\\BadCredentialsException(code: 0): Bad credentials. at /var/www/wallabag2/vendor/symfony/symfony/src/Symfony/Component/Security/Core/Authentication/Provider/UserAuthenticationProvider.php:89, Symfony\\Component\\Security\\Core\\Exception\\BadCredentialsException(code: 0): The presented password is invalid. at /var/www/wallabag2/vendor/symfony/symfony/src/Symfony/Component/Security/Core/Authentication/Provider/DaoAuthenticationProvider.php:65)"} []
[2024-09-17 15:13:13] security.DEBUG: Authentication failure, redirect triggered. {"failure_path":"/login"} []
Ok,
so I hacked my way into wallabag again.
I would not recommend to do it like I did but it worked.
wallabag has a CLI. You can access it in /var/www/wallabag2.
with bin/console --env=prod security:encode-password in this folder you can generate a new hashed password and salt.
You can than edit the wallabag database (with phpMyAdmin) and exchange the old salt and password of your user with the newly generated salt and password.
If you try this you do this totally in your own responsibility! Make a Backup of the old salt and password first!
Maybe you can also try the command fos:user:change-password this would omit changing the database yourself.
root@yunohost:/var/www/wallabag2# bin/console --env=prod security:encode-password
Symfony Password Encoder Utility
================================
Type in your password to be encoded:
>
! [NOTE] The command will take care of generating a salt for you. Be aware that some encoders advise to let them
! generate their own salt. If you're using one of those encoders, please answer 'no' to the question
! below.
! Provide the 'empty-salt' option in order to let the encoder handle the generation itself.
Confirm salt generation ? (yes/no) [yes]:
>
------------------ ------------------------------------------------------------------------------------------
Key Value
------------------ ------------------------------------------------------------------------------------------
Encoder used Symfony\Component\Security\Core\Encoder\MessageDigestPasswordEncoder
Encoded password ########
Generated salt #######
------------------ ------------------------------------------------------------------------------------------
! [NOTE] Make sure that your salt storage field fits the salt length: 40 chars
[OK] Password encoding succeeded
Here is the link to the wallabag docs: [Console commands · GitBook]
1 Like
@Ekpu A good discovery, but I think I’ll wait and see if a fix comes our way soon. If I attempt this, I’ll probably make a real mess of it. I usually do!!
Many thanks
Dj
And I’m not sure how this will adapt in the future to a fixed version (without this bug) with a working LDAP and so on.
Any simple resolution yet?
I do not have any new Wallabag version in my admin panel as of now.
Update to 2.5.4~ynh7, issues persists in stable.
1 Like
Restore your backup from before the update until a solution is found.
2 Likes
I am very sorry to ask a stupid question (no backup, no mercy): does the app specific backup happen automatically, and how would I re-install it?
Yes each update triggers an automated backup before it is done, so it can be restored if update fails, and a maximum of 2 (by default) are kept.
First check if you have it listed in the backup list. Then you can uninstall Wallabag and restore the backup.
I’d suggest to always make a backup of the faulty app before uninstalling : you’re never 100% sure the previous backup are working (if its file is corrupted for instance).
2 Likes
@Lapineige Thank you for the kind support
1 Like
I’m impacted too 
My backup are purged after a few days. Remarked it too late, can’t go back 
Thanks in advance for fixing it
1 Like
I have the same issue. Restoring the automatic backups that I have doesn’t fix the problem.
I do have earlier full system disk images, but it’s not worth rolling everything back on a 4TB ssd for this when all the other apps and the system itself is otherwise working fine. I’ll just wait for now.
1 Like
In that case I’d strongly suggest to always test the app right away after the upgrade.
Oh that’s new… From which version did you upgrade ?
I have same issue as @Paradroyd . The only backup I had was Version 2.5.4~ynh6
Sorry for the late reply…I’ve been away most of the weekend…
My backup (which I haven’t been able to log in to) is 2.5.4~ynh6.
Absolute worst case, I know I’ll be able to restore it by extracting the backup that’s in my out-of-band disk image (backup within a backup). I’m not going to do that unless this doesn’t get resolved for several more days, because it’d be more work than it’s worth at the moment.
I use this as you suggest and it work well !
thanks for the tip
1 Like
I can confirm that using :
sudo -u wallabag2 bin/console --env=prod fos:user:change-password
Solved the API (plugin wallabager) and weblogin. I used the “wallabag2” user to avoid permissions being wrongly switched to root.
We’ll see if nothing gets broken for next update, but for my part I am very relieved !
4 Likes
Yes, did the job - Thanks!
4 Likes