Firefly started forgetting access tokens

[avee87]

Support guidelines

• I've read the support guidelines

I've found a bug and checked that ...

• ... the documentation does not mention anything about my problem
• ... there are no open or closed issues that are related to my problem
• ... it's definitely a Firefly III issue, not me

Description

On Monday I noticed that my Firefly instance "forgot" all personal access tokens. They still show up in the list but applications such as Importer can no longer authenticate:

Error accessing "https://firefly.my-domain.com/api/v1/about?". Status code is 401. Body is: {"message":"Unauthenticated","exception":"AuthenticationException"}

I generated new tokens which seemed to fix the issue but today they stopped working again. I suspect it may coincide with instance restarts but need to test it more.

Did something change recently wrt how Firefly stores these tokens?

Debug information

Debug information generated at 2024-10-23 12:23:31 for Firefly III version v6.1.21.

System information
Item	Value
Firefly III	6.1.21 / v2.1.0 / 24 (exp. 24)
PHP version	8.3.12 (64bits) / apache2handler / Linux x86_64
BCscale	12
Error reporting	Display: Off, reporting: ALL errors
Max upload	67108864 (64 MB)
Database drivers	*mysql*, pgsql, sqlite,
Docker build	#1131, base #91

Firefly III information
Item	Value
Timezone	Europe/London + Europe/London
App environment	local, debug: false
Layout	v1
Logging	notice, stack / (empty)
Cache driver	file
Default language and locale	en_GB + equal
Trusted proxies	**
Login provider & user guard	eloquent / web
Login headers	N/A + N/A
Stateful domains
Last cron job	2024-10-22 23:00:00 (12 hours ago)
Mailer	smtp

User-specific information
Item	Value
User	#1 of 1
User flags	💳 🐷 🔧
Session start	2024-10-01 00:00:00
Session end	2024-10-31 23:59:59
View range	1M
User language	en_GB
User locale	en_GB
Locale(s) supported	en_GB.utf8: ✅ en_GB.UTF-8: ✅
User agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36

Expected behaviour

No response

Steps to reproduce

No response

Additional info

No response

[JC5]

Nothing has changed for the longest time, and my own access tokens hold up fine (so far). They do expire after about one year, that could be it?

[avee87]

Hm, this is interesting... One of the tokens was about a year old but another one was much younger - yet they both stopped working. And both "died" again just 2 days later. Will try rotating them again and report if the issue repeats.

[JC5]

Let me know. You can certainly "kill" access tokens if the public/private keypair is destroyed. This is something that Monica suffers from for example, each container reboot kills all access tokens.

However, Firefly III stores these keys in your configuration table, so they are restored after a reboot. If this process fails it could mean the access tokens get destroyed. However, this is pretty foolproof as far as I've been able to check.

Shall I convert this into a discussion in the mean time?

[quetzai]

I had the same thing happening to me on the same version of FireflyIII.
Rotating keys worked, once I'm done using it I'll report on the behaviour after:

• docker compose restart (I expect no problem there)
• docker compose up (might trigger something?

[JC5]

docker compose stop, start, restart will not give problems, I use those all the time.

docker compose up is paired with docker compose down, and that command stops containers and removes containers, networks, volumes, and images created by up.

So yeah when all your data is deleted you will need new keys.

[iLuckyW]

Hey, little late to the discussion. I recently noticed the same issue. Is there an option to mount a path in docker to a local folder, so that the person access tokens are persistent after container deletion?

[JC5]

Access tokens are already persisted across container deletion. What are you running into?

[iLuckyW]

I am sorry, yeah they are also persistent for me, now that I tried this specifically. I just had a few token become invalid in the last months, just like @avee87 describe in his post. Thought it had to do with deleting and recreating the container, as you mentioned in a post above.
Unfortunately I was not able to exactly determine when and why the token got invalid. Maybe I can spot the next time it happens