Hey Uri, The “not recommended” amounts to a trade-off: adjust your URL patterns (Adam’s approach looks good if you really must insert them after the admin URLs) or allow a potential leakage of what model exist to someone probing the site.
Turning off the catch-all view potentially allows the latter but it’s up to you to decide how serious that is for your site. It was the behaviour for ≈15 years before someone mentioned it, so exactly how serious it is for most sites if debatable. I seem to recall though that you commented on the other thread that you use HTTP Basic Auth to protect the admin site, as an additional layer. If so, unauthorised access is blocked before ever reaching Django, so you can turn off the catch all view without a worry. HTH Kind regards, Carlton On Tue, 19 Jan 2021 at 17:55, Adam Johnson <m...@adamj.eu> wrote: > I don't see the need for any change - you can insert your custom URL's > before the catch-all view with a subclass of AdminSite like so: > > class MyAdminSite(AdminSite): > def get_urls(self): > urls = super().get_urls() > return urls[:-1] + [ > # custom urls > ... > ] + urls[-1] > > On Tue, 19 Jan 2021 at 16:06, אורי <u...@speedy.net> wrote: > >> Hi, >> >> I installed Django 3.2 alpha and found out the change related to >> *final_catch_all_view*. I use *AdminSite* in my websites and I added >> some urlpatterns to the default urlpatterns. However, I want my urlpatterns >> to be after Django core's urlpatterns and not before them, so if a Django >> core urlpatterns matches a URL, it should be applied before my >> own urlpatterns. I read that it's not recommended to set >> *AdminSite.final_catch_all_view* to false, and I think it should be >> better that the "catch all" urlpattern will be applied after all >> urlpatterns, including those I defined in my website. Is it possible to add >> the "catch all" urlpattern as the very last urlpattern, after the website's >> defined urlpatterns? I think this makes more sense. >> >> Thanks, >> אורי >> u...@speedy.net >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CABD5YeF_ezAHFSwj-X8oT%3DT3%2B%3D1x%3DsC4ZH%3D7QyPshWra9__H2A%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CABD5YeF_ezAHFSwj-X8oT%3DT3%2B%3D1x%3DsC4ZH%3D7QyPshWra9__H2A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Adam > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMyDDM18v4qHBem%3D8HphoJWXZJ03bwSe8r_xpRVSnd3no8W9bg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMyDDM18v4qHBem%3D8HphoJWXZJ03bwSe8r_xpRVSnd3no8W9bg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJwKpyT9YpwE1DWT-huHC_MKkcPf-adHyAr%3DirbDtcsFNoPW7A%40mail.gmail.com.
