Opened 8 years ago

Closed 5 years ago

#28217 closed Bug (wontfix)

nested calls to functions decorated with sensitive_post_parameters produces unexpected results which parameters are considered sensitive

Reported by: Peter Zsoldos Owned by:
Component: Error reporting Version: 1.8
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

can reproduce with Django 1.8, 1.9, and 1.11

Rather than to explain in words, below is the testcase which reproduces the issue. test_all_outside_should_override_limited_inside fails, and for test_what_should_happen_when_both_have_limited_variable_list I'm not even sure what would be the correct expected result - combine the specified variable list?

from django.http import HttpRequest
from django.test import SimpleTestCase
from django.views.decorators.debug import sensitive_post_parameters


class NestingSensitivePostParameterDecoratorsTestCase(SimpleTestCase):

    def test_all_inside_should_override_limited_ones_outside(self):
        self.assertEqual(
            '__ALL__', self.get_request_sensitive_parameters(
                inner_args=[],
                outer_args=['foo', 'bar']
            )
        )

    def test_all_outside_should_override_limited_inside(self):
        self.assertEqual(
            '__ALL__', self.get_request_sensitive_parameters(
                inner_args=['foo', 'bar'],
                outer_args=[]
            )
        )

    def test_what_should_happen_when_both_have_limited_variable_list(self):
        self.assertEqual(
            ('bar', 'foo'), self.get_request_sensitive_parameters(
                inner_args=['foo'],
                outer_args=['bar']
            )
        )

    def get_request_sensitive_parameters(self, inner_args, outer_args):
        @sensitive_post_parameters(*outer_args)
        def outer(request):
            return inner(request)

        @sensitive_post_parameters(*inner_args)
        def inner(request):
            return 'response'

        request = HttpRequest()
        outer(request)
        return request.sensitive_post_parameters

Change History (4)

comment:1 by Tim Graham, 8 years ago

I'm not sure if it's worth trying to support this use case. The @sensitive_post_parameters decorator is documented to be used on a view. Do you have a use case for nested views like this?

in reply to:  1 comment:2 by Peter Zsoldos, 8 years ago

Replying to Tim Graham:

I'm not sure if it's worth trying to support this use case. The @sensitive_post_parameters decorator is documented to be used on a view. Do you have a use case for nested views like this?

The use case we ran into was extending the login view

In https://github.com/PaesslerAG/django-act-as-auth/blob/master/djactasauth/views.py the public app only has a dumbed down custom view, but in the internal app we use there is more customization going on in the login page (request based varying extra context, custom redirects based on user rule, etc.). However, we didn't want to copypaste the login logic, so we just use the django.contrib.auth.views.login view function to deal with that - thus inside our own decorated view we call another decorated view (aside: in this case we actually would prefer overriding the django contrib sensitive params, as the username for djactasauth would be pretty helpful debug info).

comment:3 by Tim Graham, 7 years ago

Triage Stage: UnreviewedAccepted

I don't know. As you said, the expected behavior isn't clear. If you want to try a patch, I'll take a look.

comment:4 by Carlton Gibson, 5 years ago

Resolution: wontfix
Status: newclosed
Triage Stage: AcceptedUnreviewed

Given the lack of patch, after 3 years, and that's it's probably unsupported usage, I'm going to call this wontfix.

Very happy to look at a patch if anyone wants to attempt one. (Please do reopen if so.)

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