final_catch_all_view

[אורי‎]

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

[Adam Johnson]

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]

--
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-develop...@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.

--

Adam

[Carlton Gibson]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM18v4qHBem%3D8HphoJWXZJ03bwSe8r_xpRVSnd3no8W9bg%40mail.gmail.com.

[אורי‎]

Hi Adam,

I think it's better not to rely on the number of "catch all" urlpatterns to be 1. I suggest it's better to separate AdminSite.get_urls into 3 functions - one returning all urls like before (without the "catch all" urlpattern), one returning a list containing only the "catch all" urlpattern, and one calling both functions and concatenating the lists. This way I will be able to define the first function in my own AdminSite class, add my own urlpatterns and return the list, and Django will do everything else for me. Instead of using urls[:-1] and urls[-1], there should be functions returning these lists, which I will be able to override and add my own urlpatterns. I think this approach is better than relying on the number of "catch all" urlpatterns to be 1.

Also, this feature will break all Django admin sites, unless the name of the function AdminSite.get_urls will remain the same and this function will not change, but the 2 other functions will be new functions and Django will call the third function (with all urls) instead of calling AdminSite.get_urls.

אורי

u...@speedy.net

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM18v4qHBem%3D8HphoJWXZJ03bwSe8r_xpRVSnd3no8W9bg%40mail.gmail.com.