DATABASES setting for async usage

[Andrew Wang]

Hi, I'm intrigued in helping develop the async ORM engines (link to random 
PR  with aiosqlite and base 
async engine). The biggest road block is having test cases for async 
engines only; for instance, introspection/test_async.py can't run because 
the test suite needs to first migrate using a sync engine as the default 
database connection then switch the default alias to using an async engine; 
additionally, for most of the test suite, it uses the sync engine. The 
current methods I'm thinking of:

1. Each async engine would get its own CI worker. I think it's a waste of 
resources and because it wouldn't help Django users who also need to write 
test cases with both an async and sync (for migrations) engine.
2. Async and sync engines for the same database are run at the same time. 
Every async engine requires a parallel sync engine, an alias to be 
specified in the engine's DATABASES options. This way, while testing, 
migrations can be performed with a designated sync engine. This is great 
for the end user who may be async-centric; this doesn't really resolve the 
current problem. Most of the Django test suite is designed for synchronous 
db engines, so the default alias database engine will switch around a bunch 
of times.
3. Implement a test decorator that switches the default alias connection.

Lemme know if that's confusing.

Thanks,
Andrew

-- 
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/4ca69f37-cc9e-40c3-a73b-cc9a125ebaecn%40googlegroups.com.

Re: Propagating X-Frame-Options header to debug view responses on errors

['Adam Johnson' via Django developers (Contributions to Django itself)]

Thinking again: since it’s a debug view, Django could set the most
permissive X-Frame-Options header on debug 500 responses. This would help
every kind of framed view.

If anyone agrees, we could make a ticket.

On Fri, 28 Jan 2022 at 08:13, 'Ben Dickinson' via Django developers
(Contributions to Django itself)  wrote:

> 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)  wrote:
>>
>>> Hi all,
>>>
>>> I'm one of the maintainers of 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
>>> , but in
>>> brief:
>>>
>>> On Django >= 3.0, if a user has DEBUG = True in their settings, although our
>>> template rendering view
>>> 
>>> 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
>>> 
>>> .
>>>
>> --
> 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
> 
> .
>

-- 
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/CAMyDDM3rwgXQ%3D-_XWCe-5MJsFNwu7-6-y0_4p8%2BY7KR-nZnCig%40mail.gmail.com.

Re: Propagating X-Frame-Options header to debug view responses on errors

['Ben Dickinson' via Django developers (Contributions to Django itself)]

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)  wrote:
>
>> Hi all,
>>
>> I'm one of the maintainers of 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 
>> , but in 
>> brief:
>>
>> On Django >= 3.0, if a user has DEBUG = True in their settings, although our 
>> template rendering view 
>> 
>>  
>> 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
>>  
>> 
>> .
>>
>

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