Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#8611 closed (fixed)

Reverse for '<django.contrib.auth.decorators._CheckLogin object at 0x8ee144c>' not found

Reported by: imbaczek@… Owned by: nobody
Component: Core (Other) Version: 1.1
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

this happens when trying to get a reverse for a function decorated with @login_required.

Change History (10)

comment:1 follow-up: Changed 7 years ago by oyvind

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

this is for django development, not support requests, use named urls instead

comment:2 in reply to: ↑ 1 Changed 6 years ago by Wernight

  • Component changed from Uncategorized to Core framework
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from SVN to 1.0

Replying to oyvind:

this is for django development, not support requests, use named urls instead

What's that supposed to mean? Is @login_required or reverse() for development only? What do you mean by "use named urls"; do you mean hard coding the full URL making the application to a force URL?

I got the same problem on Django 1.02 final

comment:3 Changed 6 years ago by Alex

  • Resolution set to invalid
  • Status changed from reopened to closed

What oyvind meant was that this is known to work in Django, trac is not for support requests, that's what the mailing list and IRC are for.

comment:4 follow-up: Changed 6 years ago by ogdoad8

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 1.0 to 1.1

I was getting this error when passing a floating point numeric variable (by accident) instead of a string variable as the view argument in my {% url view.here variable %}.
Hopefully this comment will help somebody.

In this case, this was probably the most unhelpful error I've ever seen! Am re-opening so that maybe some type-checking can be done in Django to make for a more helpful error message.

You can reproduce this by passing a floating point value (ints don't trigger this) to a template and using that variable as a view argument that's expecting a string.

comment:5 in reply to: ↑ 4 Changed 6 years ago by kmtracey

  • Resolution set to invalid
  • Status changed from reopened to closed

Replying to ogdoad8:

In this case, this was probably the most unhelpful error I've ever seen! Am re-opening so that maybe some type-checking can be done in Django to make for a more helpful error message.

This is a bit too vague to be useful as a suggested improvement. Type-checking what, exactly?

You can reproduce this by passing a floating point value (ints don't trigger this) to a template and using that variable as a view argument that's expecting a string.

Again, you've left out a lot of details so I have to guess what pattern you might be using, etc. Guessing you have a pattern like:

    (r'^thing/(?P<pk>\d+)/$', 'thing_detail'),

If you then try in a template:

  {% url thing_detail magic_number %}

where magic_number is a float variable in the context, the attempt to reverse will fail because the string representation of the float will have a decimal point in it, thus will not patch the \d+ pattern. Integers work because their string representation matches the pattern. But it would be perfectly legitimate to have a url pattern that did match the string representation of a float, so it isn't like the url tag can arbitrarily reject float arguments. The best it can do is say there is no pattern that matches what you've passed it.

If you've got a specific suggestion for improvement feel free to open a new ticket with recreation details including exactly what you are doing, what message you get, what you think would be better, and how you think Django could actually accomplish that. So far as I can tell what you are asking for here is not something that is possible.

comment:6 Changed 6 years ago by lukeplant

It would be much more helpful if the error message said <path.to.your.view.function> rather than <django.contrib.auth.decorators._CheckLogin object at 0x8ee144c>. I'll have a look at doing this.

comment:7 Changed 6 years ago by lukeplant

See r11482. (For some reason a comment was not automatically posted here). I don't know if this addresses your problem, but it might help.

comment:8 Changed 6 years ago by Suor

  • Resolution invalid deleted
  • Status changed from closed to reopened

Actual problem is not wrapping view carefully, I used my own decorator which used functools.wraps decorator to wrap wrapper function and view function
was reported right in reverse error.

comment:9 Changed 6 years ago by lukeplant

  • Resolution set to fixed
  • Status changed from reopened to closed

Suor - I don't understand your comment or why you reopened the ticket. Currently all our decorators use functools.wraps (or equivalent) as far as I know, and the view functions are now reported correctly in the NoReverseMatch error. Also, before r11482 it was not enough simply to use correct wrapping, because callables like _CheckLogin (or MethodDecoratorAdaptor) would still display the unhelpful message given above. Or did you re-open by mistake?

comment:10 Changed 6 years ago by Suor

Sorry, for reopening. I am using 1.1 release where error message is still incorrect.

Note: See TracTickets for help on using tickets.
Back to Top