florimondmanca / djangorestframework-api-key

🔐 API key permissions for Django REST Framework
https://florimondmanca.github.io/djangorestframework-api-key/
MIT License
669 stars 103 forks source link

Hide DRF's browsable API page title when API Key is missing/invalid #259

Closed stefanofusai closed 6 months ago

stefanofusai commented 8 months ago

As the title of this issue explains, I would like to know if there's a way to replace DRF's browsable API page title with 403 (or anything else, for that matter) when the API Key is either missing or invalid.

The reasoning behind this request is that even if the user doesn't have permission to access the API, he can get a good understanding of which endpoints are valid or not (whether the page title includes Handler 404 or the view name, in my case) and a look at what the view names are. Furthermore, in case of ViewSets, one could get a look at how the ViewSet is structured with its List/Retrieve clickable links at the top of the browsable API's response.

The components I'm referring to are div.page-header, the page's title and the link that redirects to the view's path, just above div.page-header.

image image

stefanofusai commented 7 months ago

Another part of the response that would be useful to hide is the view's name when hovering the request method button. See screenshots below.

image image image

stefanofusai commented 6 months ago

It would also be nice to hide the username on top right, if possible image

florimondmanca commented 6 months ago

Hey there,

I havent played much with the browsabke API for some some time.

I'm assuming there's the question of whether DRF processes permissions before or after routing -- I suppose it does it before.

One possibility I guess would be to add a permission check on an entire group of routes, such as on an /api/ prefix.

It's also possible a lot of this should be considered within the scope of the DRF, as questions to ask there or feature requests for them. Eg I am not aware of mechanisms to customise the browable API from permission classes or views.

If anyone else would like to chip in with possible improvements, that would be much appreciated.

For now I don't think there's much this package can do and I'll transfer this to a discussion. We can open issues if/when we find well defined improvements we can make.

Thanks?