Backup restore message doesn't mention token exports

[aemogie]

Steps to reproduce

1. Go to create backup
2. Select tracker logins
3. Create backup
4. Log out of tracker
5. Restore backup

Expected behavior

The restore backup message should indicate that the backup includes tracker login tokens.

Actual behavior

The message doesn't mention login tokens and instead says the trackers aren't logged into. But if you go to the tracker settings after the restore, the login tokens have been restored and you're logged back in.

Crash logs

No response

Tachiyomi version

0.16.0

Android version

Android 12

Device

Samsung Galaxy M02

Other details

No response

Acknowledgements

• [X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
• [X] I have written a short but informative title.
• [X] If this is an issue with an official extension, I should be opening an issue in the extensions repository.
• [X] I have gone through the FAQ and troubleshooting guide.
• [X] I have updated the app to version 0.15.3.
• [X] I have updated all installed extensions.
• [X] I will fill out all of the requested information in this form.

[suyash01]

This message could be set up as tokens can expire and you may have to re login even after backup. I am not sure about the expiry time of the tokens.

However I am completely against the idea of backing up auth tokens even if the backup is encrypted.

[MajorTanya]

However I am completely against the idea of backing up auth tokens even if the backup is encrypted.

Whether or not the backup includes tokens is something the user has to decide when they create a backup. For manual ones, it's always not selected, so the user would have to explicitly decide to include the sensitive data. I don't recall what automatic ones do or don't include.

Either way, that's outside the scope of the issue as filed.

[suyash01]

What about the token expiring while in the backup, is there a way to identify that while restoring the backup?

If not then it should be phrased as such that the user may have to login in case of an expired token.

[MajorTanya]

What about the token expiring while in the backup, is there a way to identify that while restoring the backup?

If not then it should be phrased as such that the user may have to login in case of an expired token.

I don't believe Mihon knows the token's expiry necessarily, but theoretically, it could attempt a call to the included tracker(s) with the token at hand. If it's expired, the tracking service would respond as such, and if it's not, the call would go through successfully. Just spitballing here, there might be an offline-first solution I'm missing (or maybe backups do include expiry data).

[MajorTanya]

Investigated a bit more and at least for some trackers, the access & refresh tokens are stored with their respective expiry time. The credentials for logging in, which are included as well, do not carry expiry information (which would make some sense). Therefore, checking the expiry of the access/refresh tokens should be possible locally, but notifying the user of having to log in again might need some type of notification or label somewhere easily visible (not buried in the tracking menu itself)