2FAuth "An error occured: Already authenticated, please log out first"

[wbk]

What type of hardware are you using: Other(?)
What YunoHost version are you running: 12.0.11
What app is this about: 2fauth

Describe your issue

Hi all,

My 2FAuth didn’t work anymore after upgrading from 5.2.0~ynh2 to 5.4.3~ynh1.

After restoring the backup, I was still not able to use the (old version of the) app.

When trying to use the app:

• I go to the 2fauth.domain.tld URL
• I enter my email address and password, click “Login”
• Nothing happens
• I enter my email addres and password again, click “Login” once more
• An error is displayed, “An error occured: Already authenticated, please log out first”
  • I can chose “Close” or “Back to home” (which points at 2fauth.domain.tld/accounts)
• “Close” returns me to the login screen
• “Back to home” does not work most of the time; of 5-10 clicks, maybe once I’ll be forwarded to the application
• If so being forwarded, I’m presented with an empty list of 2FAs: “No 2FA here! Pick a method and add your first account”
  • Here is a “Sign out” link, besides “Settings” and “Admin” (this user is admin)
  • Clicking “Admin” gives an error in red on top, “Data can not be refreshed from the server”
  • Admin settings are available though; the “Users” gives an error, “An error occured: s.response is undefined”
  • Settings are available, but my settings have disappeared (I did clear cookies and data in my browser in an earlier attempt to log out)

All in all it seems the datastore for 2FAs has disappeared.

The dockerfile has the database configured at /srv/database/database.sqlite, for which I’m unable to locate a volume.

In the 2FAuth directory under /var/www/2fauth/ there is a directory storage/app/qrcodes that has only a .gitignore file, no qrcodes. The log directory there has only logs about the app version.

Before I dive in a backup of the machine, where should I look?

Share relevant logs or error messages

There is no error in the upgrade log: https://paste.yunohost.org/raw/oxuwizusub

The nginx-error log is empty, the access log has nothing that catches my eye.

[jarod5001]

Did you clear browser data for the app url? Or use private window?

[wbk]

I did “Clear cookies and site data”, but hadn’t tried a private window yet.

A private window does tell me that I already logged in after the second attempt, but in that case the ‘Back to home’ button does not bring me to the (empty) app, but brings me back to the login page instead.

There is no way to log out in that case.

Returning to the non-private window, this is how it looks like after “Go back home” on the “Already logged in” page:

Quite as if it has never been populated

The annoying thing is that this the restored version of the app. I don’t have another Yunohost-app-backup of 2FAuth; the container backup is either all-or-nothing or file-by-file.

The database location is configured in the .env file, which points to the non-existant location down /srv/.... mentioned above.

Browsing the (un)install / restore / backup script I noticed

#=================================================
# BACKUP THE MYSQL DATABASE
#=================================================
ynh_print_info "Backing up the MySQL database..."
ynh_mysql_dump_db > db.sql

where I had expected a SQLite database (another configuration file mentioned ‘only SQLite supported’, but I can’t find it back now).

Connecting to the database, select * from twofaccounts; lists my accounts, so the data is still there. Hmmm

Ah, wait, the ambiguous configuration file is .Dockerfile, which has sections

    # Database config & credentials
    # DB_CONNECTION can only be sqlite
    DB_CONNECTION=sqlite \
    DB_DATABASE="/srv/database/database.sqlite" \

And the somewhat worrisome

    # The encryption key for  our database and sessions. Keep this very secure.
    # If you generate a new one all existing data must be considered LOST.
    # Change it to a string of exactly 32 chars or use command `php artisan key:generate` to generate it
    APP_KEY=SomeRandomStringOf32CharsExactly \

That key there just may not be the actual key that should have been generated (or restored) in place there. Seeing a change there makes data considered lost, it may well be the culprit.

Hmmmm, again.

[jarod5001]

Hello, sorry for the late reply.
Did you get it working?
The settings are stored in the .env file. And from what I see in the yunohost package, the app key is left empty. So I don’t think that the data is encrypted.
Check the .env file. And try to a new clean install, drop the database and import the database from the backup.

[wbk]

@jarod5001

Hello, sorry for the late reply.
Did you get it working?

No worries, thanks for your suggestions, but no, not yet any improvement the last couple of days.

@jarod5001

The settings are stored in the .env file. And from what I see in the yunohost package, the app key is left empty.

The .env file does shine another light. It seems to be filled at one step or another

# The encryption key for your database and sessions. Keep this very secure.
# If you generate a new one all existing data must be considered LOST.
#
# You can leave this empty if you use `php artisan 2fauth:install`.
# Otherwise, change it to a string of exactly 32 chars or use command
# `php artisan key:generate` to generate it.

APP_KEY=YMEtX....bG1WaU5PaH

A step in the upgrade process might have triggered generation of a new key. I’ll compare it to a backup.

The data seems encrypted, dumping the database and importing it to a new install probably does not make it readable without the proper key:

MariaDB [2fauth]> select * from twofaccounts limit 1;
+----+---------+----------+---------+------------------------------------------------------+-----------------+------+---------------------+---------------------+--------------+----------+---------+-----------+--------+--------+---------+
| id | user_id | group_id | service  | legacy_uri             | account                                | icon | created_at          | updated_at     | order_column | otp_type | secret                        | algorithm | digits | period | counter |
+----+---------+----------+---------+-------------------+-----------------------------------+------+---------------------+---------------------+--------------+----------+-------------------------+-----------+--------+--------+---------+
|  1 |       1 |        1 | TMP(sys) | eyJpdiI6IlV...mRjZIiJ9 | eyJpdiI6I...DkwMmEiLCJ0YWciIifQ== | NULL | 2024-04-08 21:56:56 | 2024-10-07 10:44:56 |           32 | totp     | eyJp....IjoiIn0= | sha1      |      6 |     30 |    NULL |
+----+---------+----------+---------+------------------------------+----------------------+------+---------------------+---------------------+--------------+----------+-----------+-----------+--------+--------+---------+
1 row in set (0.000 sec)

If all else fails, I’ll populate from an export of Aegis from my phone, which I have tried to keep relatively in-sync.

I’ll post back the way I took in the end; if someone comes by with a helpful hint I’m all ears!