[Django] #35720: Problem with getattr Handling in _resolve_lookup Method

18 views
Skip to first unread message

Django

unread,
Aug 29, 2024, 3:31:17 PM8/29/24
to django-...@googlegroups.com
#35720: Problem with getattr Handling in _resolve_lookup Method
-------------------------------------+-------------------------------------
Reporter: Mohammad Salehi | Type: Bug
Status: new | Component: Template
| system
Version: 5.0 | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Hello,

While working on issue #35673, which deals with handling `request.GET`
when the number of query parameters exceeds the limit set in
`settings.DATA_UPLOAD_MAX_NUMBER_FIELDS`, I discovered another problem
with the _resolve_lookup method in the `Variable` class inside
`template/base.py`. When `request.GET` encounters an error, it causes
issues in the _resolve_lookup method. Specifically, when the code tries to
access GET and uses the `getattr` function, this function does not handle
errors properly, which leads to further problems in the system.

I believe there are two solutions: or the `getattr` function should be
modified to handle errors correctly, or the underlying cause of the error
in `getattr` should be addressed. It would be best to discuss this with
the other team members to determine the best approach and then implement
the necessary changes.
--
Ticket URL: <https://code.djangoproject.com/ticket/35720>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Aug 29, 2024, 3:31:50 PM8/29/24
to django-...@googlegroups.com
#35720: Problem with getattr Handling in _resolve_lookup Method
---------------------------------+--------------------------------------
Reporter: Mohammad Salehi | Owner: (none)
Type: Bug | Status: new
Component: Template system | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Changes (by Mohammad Salehi):

* version: 5.0 => dev

--
Ticket URL: <https://code.djangoproject.com/ticket/35720#comment:1>

Django

unread,
Aug 30, 2024, 10:31:17 AM8/30/24
to django-...@googlegroups.com
#35720: Problem with getattr Handling in _resolve_lookup Method
---------------------------------+--------------------------------------
Reporter: Mohammad Salehi | Owner: (none)
Type: Bug | Status: closed
Component: Template system | Version: dev
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Changes (by Sarah Boyce):

* resolution: => needsinfo
* status: new => closed

Comment:

Would you mind writing a test demonstrating the issue you think should be
solved here? Or could you provide a minimal reproducible example, or a
stack trace?
--
Ticket URL: <https://code.djangoproject.com/ticket/35720#comment:2>

Django

unread,
Sep 3, 2024, 5:25:52 AM9/3/24
to django-...@googlegroups.com
#35720: Problem with getattr Handling in _resolve_lookup Method
---------------------------------+--------------------------------------
Reporter: Mohammad Salehi | Owner: (none)
Type: Bug | Status: closed
Component: Template system | Version: dev
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Comment (by Mohammad Salehi):

Thanks for your response. I understand the need for a clear display of the
issue. The problem I discovered is directly related to the test you wrote
for issue #35673.

In the original code, there was an infinite loop caused by the way
request.GET was accessed. In `views/debug.py`:


{{{
c["request_GET_items"] = self.request.items()
}}}


I resolved this issue by modifying the code to:


{{{
c["request_GET_items"] = self.request.META.get("QUERY_STRING", "")
}}}

This fix breaks the loop and allows the program to continue execution.
However, after this change, another issue became apparent in the
_resolve_lookup method when the code encounters GET during the lookup
process.

Specifically, the issue arises here in `template/base.py` in line 893:

{{{
current = getattr(current, bit)
}}}

When bit is GET, getattr fails to handle it correctly, leading to an
error. This seems to be the root cause of the problem that needs
addressing.

I believe that fixing the loop in the original test (issue #35673) will
allow us to reproduce on this getattr error. It would be great to discuss
with the team whether we should modify getattr to handle this scenario
better or if we need to address the issue in another part of the code.


It way is you see this error.
--
Ticket URL: <https://code.djangoproject.com/ticket/35720#comment:3>

Django

unread,
Sep 11, 2024, 5:52:52 AM9/11/24
to django-...@googlegroups.com
#35720: Problem with getattr Handling in _resolve_lookup Method
---------------------------------+--------------------------------------
Reporter: Mohammad Salehi | Owner: (none)
Type: Bug | Status: closed
Component: Template system | Version: dev
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
---------------------------------+--------------------------------------
Comment (by Sarah Boyce):

I think we are still missing a clear way to replicate this issue on main -
a test or a minimal project to replicate the issue is needed.

This currently describes a scenario that is dependent on how another
ticket is handled, and so it is not clear whether this needs a new ticket
or can be handled in the existing ticket #35673. Ideally, an external
person can read the ticket and understand it without being sent to another
ticket
--
Ticket URL: <https://code.djangoproject.com/ticket/35720#comment:4>
Reply all
Reply to author
Forward
0 new messages