You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have some custom renderers that render data in CSV format. These renderer classes are used on views that require authentication. I recently noticed that if an unauthenticated request comes in for one of these views, DRF will still pass the "permission denied" exception to the custom renderer for rendering. In my case, this was resulting in a failure because my CSV renderer was being passed data it wasn't expecting. I could probably change the renderers to check whether they are being passed an exception and render JSON instead, but perhaps it might make sense for renderers to be able to mark themselves as exception-handling or not?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have some custom renderers that render data in CSV format. These renderer classes are used on views that require authentication. I recently noticed that if an unauthenticated request comes in for one of these views, DRF will still pass the "permission denied" exception to the custom renderer for rendering. In my case, this was resulting in a failure because my CSV renderer was being passed data it wasn't expecting. I could probably change the renderers to check whether they are being passed an exception and render JSON instead, but perhaps it might make sense for renderers to be able to mark themselves as exception-handling or not?
Beta Was this translation helpful? Give feedback.
All reactions