Yes, I'm an idiot. I had commented out the middleware when debugging
and forgot to put them back.
On Mon, Feb 29, 2016 at 10:09 AM, knbk <marten.knbk@gmail.com> wrote:
> That would happen if the AuthenticationMiddleware hasn't run. In what
> context is request.user missing?
>
> On Monday, February 29, 2016 at 3:54:24 PM UTC+1, Larry....@gmail.com wrote:
>>
>> So does anyone know why there would be a no user attr? I would expect
>> this:
>>
>> (Pdb) request.user
>> <django.utils.functional.SimpleLazyObject object at 0x10c424850>
>>
>> But I get this:
>>
>> (Pdb) request.user
>> *** AttributeError: 'WSGIRequest' object has no attribute 'user'
>>
>> On Sat, Feb 27, 2016 at 6:31 PM, Larry Martell <larry....@gmail.com>
>> wrote:
>> > Yes, you are absolutely correct. Thanks for directing me away from
>> > that red herring. But it seems request.user no longer exists.
>> >
>> > There is code that does this:
>> >
>> > if request.user.is_authenticated():
>> >
>> > which throws:
>> >
>> > AttributeError: "'WSGIRequest' object has no attribute 'user'"
>> >
>> > On Sat, Feb 27, 2016 at 5:48 PM, knbk <marte...@gmail.com> wrote:
>> >> I was referring to the wrong release notes. The rights one can be found
>> >> in
>> >> the 1.8 release notes in the miscellaneous section[1]:
>> >>
>> >>> HttpRequest now has a simplified repr (e.g. <WSGIRequest: GET
>> >>> '/somepath/'>). This won't change the behavior of
>> >>> theSafeExceptionReporterFilter class.
>> >>
>> >>
>> >> Printing the request in your debugger is nothing more than calling repr
>> >> on
>> >> the request and displaying the result. The conclusion is the same: the
>> >> request is not empty, but the string representation of the request has
>> >> changed. This is unrelated to whatever issue you're facing.
>> >>
>> >> [1] https://docs.djangoproject.com/en/1.9/releases/1.8/#miscellaneous
>> >>
>> >> On Saturday, February 27, 2016 at 11:21:18 PM UTC+1,
>> >> Larry....@gmail.com
>> >> wrote:
>> >>>
>> >>> On Sat, Feb 27, 2016 at 5:14 PM, knbk <marte...@gmail.com> wrote:
>> >>> > The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is
>> >>> > not
>> >>> > an
>> >>> > accurate description of what is actually contained in the request,
>> >>> > and I
>> >>> > doubt it has anything to do with the actual issues you're facing.
>> >>> >
>> >>> > [1]
>> >>> >
>> >>> >
>> >>> > https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting
>> >>>
>> >>> I am printing the request object from the debugger:
>> >>>
>> >>> (Pdb) request
>> >>> <WSGIRequest: GET '/'>
>> >>>
>> >>> This is not in the debug page. I'm pretty sure it's empty as when I
>> >>> call login(request) I get a blank page with a 200 back.
>> >>>
>> >>> >
>> >>> > On Saturday, February 27, 2016 at 11:09:28 PM UTC+1,
>> >>> > Larry....@gmail.com
>> >>> > wrote:
>> >>> >>
>> >>> >> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider
>> >>> >> <jrschn...@gmail.com> wrote:
>> >>> >> >
>> >>> >> > On Feb 27, 2016 1:55 PM, "Larry Martell" <larry....@gmail.com>
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> Anyone have any insights on this? Is there anything special I
>> >>> >> >> need
>> >>> >> >> to
>> >>> >> >> do get the request structure? The way this 1.9 site is now, it
>> >>> >> >> doesn't
>> >>> >> >> work at all because the request structure is not getting passed
>> >>> >> >> in.
>> >>> >> >>
>> >>> >> >
>> >>> >> > I'd be most suspicious of middle ware not handling the request
>> >>> >> > correctly.
>> >>> >>
>> >>> >> I tried removing all the middleware, but I got the same result.
>> >>> >> This
>> >>> >> is the middleware that was in place:
>> >>> >>
>> >>> >> 'django.middleware.security.SecurityMiddleware',
>> >>> >> 'django.contrib.sessions.middleware.SessionMiddleware',
>> >>> >> 'django.middleware.common.CommonMiddleware',
>> >>> >> 'django.middleware.csrf.CsrfViewMiddleware',
>> >>> >> 'django.contrib.auth.middleware.AuthenticationMiddleware',
>> >>> >>
>> >>> >> 'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
>> >>> >> 'django.contrib.messages.middleware.MessageMiddleware',
>> >>> >> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
>> >>> >> 'django.middleware.security.SecurityMiddleware',
>> >>> >>
>> >>> >>
>> >>> >> > Have you tried moving to a fresh venv to ensure Django and other
>> >>> >> > packages
>> >>> >> > aren't damaged?
>> >>> >> >
>> >>> >> > Can you replicate the issue on a separate test server?
>> >>> >>
>> >>> >> No, I haven't tried either one yet. I guess I will have to do that,
>> >>> >> but I really would like to just get this setup working.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CACwCsY63rjWxpF-O2KP0tKzmYkcD7vJCw0OinSnCds%2BarDwxfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment