Possible regression with 3.2.10 and admin.ModelAdmin.change_view()

[mike dewhirst]

I'm using the Admin with Stripe - which works nicely up until Django 3.2.9. Beyond 3.2.9 it still interacts with Stripe correctly and Stripe logs show no errors.

However, from 3.2.10 up to 4. 0.x the following error occurs after a successful acquisition of the Stripe payment token and after Stripe has pocketed the money:

ValueError at /admin/polls/question/1/change/payment/change/

Field 'id' expected a number but got '1/change/payment'.

The program flow in the payment view is to save the Stripe token into a field to indicate that payment has been received.

The project is in production and hereby locked into 3.2.9

[mike dewhirst]

Working SQLite based Polls project demonstrating the error

[Carlton Gibson]

This is almostly certainly a consequence of 333c65603032c377e682cdbd7388657a5463a05a for CVE-2021-44420.

Your URL patterns end with $ so they'll be matches against a fullmatch() rather than a search().

How exactly that's leading to the error is hard to see — Whilst you've given a sample project, there's too much noise in it to with all the Stripe code (which isn't runnable as provided) to spot what's going in in Django.

Steps forward would be to isolate the Django code, and show how the value is coming up. (Can you add a test case to the test.py that fails, so giving a traceback, but doesn't involve hitting the Stripe API?)

/admin/polls/question/1/change/payment/change/

Where exactly is that URL being generated? The 1 is correct but then it's getting the extra payment/change/ added on.

Almost certainly, the change is behaviour is just a consequence of the security fix, so not something we'd revert. But that it's causing an issue for you implies an issue in your code to address.

[Carlton Gibson]

Playing further to reproduce the error:

`
object_id: '1/change/payment'
request: <WSGIRequest: GET '/admin/polls/question/1/change/payment/change/'>
`

When trying to resolve the URL in the admin.

The question you need to answer is why the 1/change/payment is being generated.

This isn't something we can solve for you, but I'd advise using reverse() rather than building URLs with string formatting.

Happy to look again if you can demonstrate an issue in Django.
Good luck.