Django-allauth: Please log OAuth2 authentication failures

Created on 6 Sep 2015 · 6Comments · Source: pennersr/django-allauth

OAuth2 view here doesn't log failures, making them very tricky to debug.

Feature request

Source

Almad

👍5 ❤1

Most helpful comment

This bit us really badly today. The workaround described by @zags only got us this output:
Code: unknown, Error: None

I think we really need some better logging here asap

rorito on 6 Jul 2016

👍2

All 6 comments

This would be helpful as I'm currently having trouble w/ Instagram logins (https://github.com/pennersr/django-allauth/issues/1220)

manlycode on 21 Dec 2015

Any update on this? Debugging OAuth login failures is currently a pain. "Social Network Login Failure" is not very informative on its own.

zags on 19 Apr 2016

👍1

I have a temporary workaround posted here: http://stackoverflow.com/a/36728888/2800876

zags on 19 Apr 2016

This bit us really badly today. The workaround described by @zags only got us this output:
Code: unknown, Error: None

I think we really need some better logging here asap

rorito on 6 Jul 2016

👍2

For those wondering, it's pretty easy to add explicit logging (eg. to an instrumentation server) by overriding the authentication_error method on an adapter.

Example: https://github.com/HearthSim/HSReplay.net/blob/0c20282dfa75f639bd12a0ca689d4ffa7bdee80d/hsreplaynet/accounts/providers.py#L14

jleclanche on 19 Feb 2017

👍1

This bit us really badly today. The workaround described by @zags only got us this output:
Code: unknown, Error: None

I agree, and I apologize in advance that my case is a bit non-common.. but I was trying to make a Read the Docs' development settings work in a UWSGI deployment, which can seem a bit silly and probably is. But while doing this, I really missed better debugging info.

Injecting logging statements directly in to allauth's codebase helped me identify the issues.

If you are faced with similar issues, check that...

...the cache backend settings.CACHE_BACKEND is shared (e.g. memory-based caching isn't shared across UWSGI workers)
...same goes for the session engine, use the default database backed and ensure that your database is writable
...session cookie configuration works and is readable from your instances, I found an empty request.session dict during debugging
Try setting SOCIALACCOUNT_STORE_TOKENS=True
I had django-debug-toolbar's middleware inserted before the session middleware, and that broke stuff, too