SimpleLazyObject issue in TemplatesPanel

[andyhasit]

I'm getting an error when debug_toolbar.panels.templates.TemplatesPanel is enabled.

Cannot query "andrew": Must be "User" instance.

Which is triggered at line 115 in debug_toolbar/panels/templates/panel.py.

The problem is the value is a SimpleLazyObject and this may be social_django's fault so I'm not sure if this is an issue which belongs here or over there.

Can someone have a look and let me know who's camp it falls in? Happy to do fix and PR myself if I'm pointed in right direction but I'm a bit scuppered for now.

Full paste here

Django==2.1.5
django-debug-toolbar==1.11
social-auth-app-django==3.1.0

[matthiask]

It's not the first time that I see problems of this type where request.user's SimpleLazyObject fails to materialize "early enough" to either an user or AnonymousUser instance.

These problems also happened in production where django-debug-toolbar isn't running (on our sites at least) so I'd say it's probably not django-debug-toolbar's fault. python-social-auth may neither be at fault, maybe it's just the inherent brittleness of the lazy proxy object but that doesn't help you much... :-(

Just out of interest and maybe also inspired by https://stackoverflow.com/a/11315674/317346 -- what happens if you add e.g. an access to request.user.is_authenticated somewhere or if you filter by user.id instead in https://github.com/python-social-auth/social-app-django/blob/ce15088d2bf04a87eb60a46eb6cbb882060ab45c/social_django/storage.py#L121 ?

[matthiask]

Also, python-social-auth has a terrible amount of code just for solving the problem of authenticating with some OAuth2 services... :-(

[andyhasit]

I suppose I could get round this by accessing the object earlier with middleware, but that's some hack just to get this working. I tried reordering the loading order of various things (it's currently the last in middleware) but that's made no difference.

It's not an issue in my project as such, just raised the ticket as I thought it might be an issue in debug-toolbar which might be easily resolved by accessing the pk in the line before of something? Thing is, I've just changed my models around and now can't reproduce. I think (and I mean think) it may have been to do with the fact I had told social auth to use my custom user model, but hadn't told normal auth to use it, which is now no longer the case...

[matthiask]

Yes it seems that this is quite an elusive bug :-/

[mariusburfey]

I can confirm that this bug only occurs if SOCIAL_AUTH_USER_MODEL and AUTH_USER_MODEL differ.

[Radren]

This patch works for me:
add these lines

if key == 'backends':
    continue

as a first line in a cycle: https://github.com/jazzband/django-debug-toolbar/blob/master/debug_toolbar/panels/templates/panel.py#L100
You should get something like that at the end:

if pformatted is None:
    temp_layer = {}
    for key, value in context_layer.items():
        if key == 'backends':
            continue
        # Replace any request elements - they have a large
        # unicode representation and the request data is
        # already made available from the Request panel.
        if isinstance(value, http.HttpRequest):
            temp_layer[key] = "<<request>>"

(works for django-debug-panel==0.8.3)

[jayvdb]

relip/django-model-repr#3 looks like another slightly different side-effect of whatever is causing this problem.

[tim-schilling]

If someone runs into this issue again in the future, please include a fullstack trace of the error.