Closed noantiq closed 6 months ago
stumpylog
commented
6 months ago Given that's allauth crashing, this seems better reported to them. There's not even a place there where paperless code is involved.
Also, OSError: [Errno 99] Cannot assign requested is just a low level network problem that is probably something about your own system.
noantiq
commented
6 months ago Hi @stumpylog thanks for the clarification. I am obviously not aware of how exactly you interact with django-allauth and where or how much paperless code is involved but the issue is not (only) about the error message that was printed to the logs and I think some if not all of my suggestions are still applicable.
I would assume that the two config options are handled by paperless, or am I wrong here? If so you could mitigate this exception altogether by not starting the signup flow at all when the value for PAPERLESS_ALLOW_SIGNUPS is set to False or by changing the logic of these flags (as suggested above).
Again, I do not know much about django and I did not look through the paperless code but when I use a library and in some scenarios that library might throw an exception effectively making my app unusable until it’s restarted I either assure that these scenarios cannot occur or at least catch the exception and show a meaningful message in the logs for an admin to check and preferably in the UI for the user to get a sense of what failed. So no matter if allauth crashed this could be handled by paperless. At least that’s my understanding, please correct me if I got something wrong.
My last suggestion was to add a remark to the docs, I think that should be possible even if nothing is changed code wise and regardless of why the error occurs in this scenario.
shamoon
commented
6 months ago You do not need PAPERLESS_ACCOUNT_ALLOW_SIGNUPS enabled. I just checked this again and signed up for an account with only:
PAPERLESS_APPS="allauth.socialaccount.providers.github,allauth.socialaccount.providers.openid_connect"
PAPERLESS_SOCIALACCOUNT_PROVIDERS='{"github": {"APPS": [{"provider_id": "github","name": "Github New","client_id": "***","secret": "***"}]}}'The error above seems to be an email thing (and doesnt mention PAPERLESS_ACCOUNT_ALLOW_SIGNUPS?). I also did the above test without any email server setup so either theres a bug in allauth (please raise the issue there as noted, see https://github.com/pennersr/django-allauth/issues ) or you just have it misconfigured.
Feel free to add more if we're missing something here, otherwise I'll close this out.
noantiq
commented
6 months ago Hi @shamoon thank you for your input. Based on your pointers I tried reproducing the crash with a clean install and investigated a bit further. I was able to reproduce it but you are correct, the PAPERLESS_ACCOUNT_ALLOW_SIGNUPS option has nothing to do with it. It simply worked when I enabled that option and restarted Paperless and thus I assumed there must be a causal relationship between these two, but the restart part actually let me log in without an error.
Nonetheless the crash on signup consistently occurs in two situations:
In both of these cases the Ul successfully forces you to enter a valid email address that is not in use already (see screenshot below), but even when you then change the email address in the Ul, after you hit that "Sign up" button you are greeted with the server error screen and log error message I described above. Apparently (guessing from the experimenting and the log output i sent) the “old” email address that was provided by the OICD provider is used to send out a confirmation mail (even when no mail server is configured).
After restarting Paperless I was able to log in using OICD and the created profile in paperless had the changed valid email address connected.
shamoon
commented
6 months ago I see that we need probably need a way to set ACCOUNT_EMAIL_VERIFICATION. Maybe more like an enhancement vs a bug but agree its unexpected
github-actions[bot]
commented
5 months ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns. See our contributing guidelines for more details.
Description
When setting up OIDC I noticed that the default settings concerning user signup contradict each other which results in an exception that leads to paperless needing a restart. As seen below the default settings disallow signups in general but allow social signups.
When setting up OIDC signups and leaving the settings as is the signup process is started as expected but fails at the final step.
Afterwards, when trying to log in with a pre-existing account paperless is not loading.
After inspecting the logs I can see that paperless failed during the signup since an exception occurred.
The docs do not mention that you have to explicitly allow signups in general - even though it might make sense.
What I suggest should happen:
Anyway, I know that the integration of social accounts came in very recently and therefore I expected some minor problems like this, but all in all it works really well so far. Thank you and keep up the excellent work!
Steps to reproduce
Webserver logs
Browser logs
No response
Paperless-ngx version
latest - 2.5.3
Host OS
should be irrelevant but RasPi OS arm
Installation method
Docker - official image
Browser
No response
Configuration changes
No response
Other
No response
Please confirm the following