jfa-go
jfa-go copied to clipboard
hrfee
Email address attribute overwritten by nulls
Read the FAQ first!
Describe the bug
Recently I have noticed that some users are losing their email addresses. This even happened with users who were registered by JFAGO and where email was mandated for jellyfin access.
To Reproduce
Not quite sure how to reproduce. I checked the logs and found nothing that indicated any issues. Closest I can see would be either something is allowing a null overwrite of email when saving settings or this error below
_
Failed to authenticate with Jellyfin @ "https://x.net": runtime error: invalid memory address or nil pointer dereference
_
Logs
If you're using a build with a tray icon, right-click on it and press "Open logs" to access your logs.
When you notice the problem, check the output of jfa-go or get the logs by pressing the "Logs" button in the Settings tab. If the problem is not obvious (e.g a panic (red text) or 'ERROR' log), re-run jfa-go with the -debug argument and reproduce the problem. You should then take a screenshot of the output, or paste it here, preferably between ``` tags (e.g ````Log here\``). Remember to censor any personal information.
If nothing catches your eye in the log, access the admin page via your browser, go into the console (Right click > Inspect Element > Console), refresh, reproduce the problem then paste the output here in the same way as above.
Configuration
If you see it as necessary, include relevant sections of your config.ini, for example, include [email] and [smtp]|[mailgun] if you have an email issue.
Platform/Version
Docker on Ubuntu
I logged in today and noticed that 2 more users have lost their email address. I checked the logs and there were exactly 2 error logs that may correspond with this. There may be some transaction that is taking place as a result of the authentication error that is modifying users.
2023/11/19 02:40:59 Failed to authenticate with Jellyfin @ "https://x.net": runtime error: invalid memory address or nil pointer dereference 2023/11/19 04:17:59 Failed to authenticate with Jellyfin @ "https://x.net": runtime error: invalid memory address or nil pointer dereference
May I ask which version you have this issue on? A specific check was added to solve this issue, ensuring that when the daemon checks if a user exists, that the error given from Jellyfin is specifically a User not found error, and not just a connection issue.
Putting myself down for the same issue. After doing user management today I noticed they were all gone. Not sure when this happened.
Currently running: JFA-GO: 0.5.0 - Commit: 084a62e (Only version I have been running) Jellyfin: 10.8.10
Users were added through JFA-GO invites.
Steps to take to replicate:
Shutdown Jellyfin server Wait for the error in the logs below to appear Bring Jellyfin backup
Emails gone after logging back into JFA-GO
Logs:
2023/12/21 06:07:27 Failed to authenticate with Jellyfin @ "http://192.168.11.10": runtime error: invalid memory address or nil pointer dereference
sorry if I didn't make it clear enough, the issue has been fixed and is available on unstable, switch to it for now.
May I ask which version you have this issue on? A specific check was added to solve this issue, ensuring that when the daemon checks if a user exists, that the error given from Jellyfin is specifically a User not found error, and not just a connection issue.
I was on docker stable the Sept release. Unstable seems to fix this. Do you know when this fix will make it to stable? I'll probably migrate back to stable as soon as this fix is available.
Thanks
Hopefully soon, i've tackled most of what I wanted to for this release. Latest is end of January but it'll probably be much earlier.
Hopefully soon, i've tackled most of what I wanted to for this release. Latest is end of January but it'll probably be much earlier.
Cheers!
If you're looking for any other quick wins, I have noticed that enabling SSL but not specifying a cert+key will effectively halt everything during launch. This was when I first started using the software but it's such a small item that it wasn't worth a feature request. Anyways, if SSL can have an exception path during launch it would be easier for the setup. Extremely low importance though