Thanks Adam, that makes sense. The middleware is good idea, I hadn't thought of that. I think that's the way to go, at least that way we can keep it scoped to our URLs.
Cheers! On Wednesday, 26 January 2022 at 19:04:33 UTC Adam Johnson wrote: > I was wondering if it would be possible to copy the value of the >> X-Frame-Options from the view that threw an error > > > The problem here is that, because the view threw an error, there is no > response object to copy the X-Frame-Options header from. So there's no way > for the middleware to know that the view *would* have set that header. > > At least as a workaround, I would suggest you add a middleware to your > package to add the header to error responses from your view(s). You might > be able to use the process_view and process_exception hooks to detect when > your views are called, and if they error. Alternatively your middleware > might just set X-Frame-Options for all url's with the prefix your app is > installed at. > > On Mon, 24 Jan 2022 at 16:17, 'Ben Dickinson' via Django developers > (Contributions to Django itself) <django-d...@googlegroups.com> wrote: > >> Hi all, >> >> I'm one of the maintainers of django-pattern-library >> <https://github.com/torchbox/django-pattern-library>, which allows >> Django templates to be rendered with dummy context provided in static >> files. These rendered versions of the templates are show in an iframe, >> which means we have a bit of a niche issue. >> >> There's a bit more context on the Github issue >> <https://github.com/torchbox/django-pattern-library/issues/129>, but in >> brief: >> >> On Django >= 3.0, if a user has DEBUG = True in their settings, although our >> template rendering view >> <https://github.com/torchbox/django-pattern-library/blob/main/pattern_library/views.py#L78> >> >> correctly sets the X-Frame-Options header to "SAMEORIGIN" on responses, if >> the rendering of the template throws an error and the user doesn't also >> have X_FRAME_OPTIONS = 'SAMEORIGIN' set in their settings, then the >> browser will block the debug response from being shown. >> >> The current solution is to instruct users to set X_FRAME_OPTIONS = >> 'SAMEORIGIN' or looser in their (development) settings, but this seems less >> than ideal to me. >> >> I was wondering if it would be possible to copy the value of the >> X-Frame-Options from the view that threw an error to the debug views' >> responses so that in the case the original response was allowed to be shown >> in an iframe, the stacktrace could be shown instead without changing the >> project-wide default of a security heading. >> >> I'd be happy to have a go at this, but from a quick look it's not >> trivial. Any thoughts about whether this would be desirable or even >> possible and guidance about how I might start would be very gratefully >> received! >> >> Cheers, >> Ben >> >> -- >> 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/29e4223f-e035-49de-8397-7043a26cae73n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/29e4223f-e035-49de-8397-7043a26cae73n%40googlegroups.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/a94cc95e-6367-4971-964e-aa535c6a7f48n%40googlegroups.com.
