Re: Model inheritance in different modules

[Steven Mapes]

It sounds to me like your data modelling is wrong. You can either have a 
one-to-one table2 acts as an extension of table1, a view that combines 
multiple tables into one "virtual table" or have one table and two models 
that use the table. One, the superset, would be managed, the other would 
only show a subset of the columns

Otherwise you risk adding fields into the subset model and assuming that 
they will be in the superset model which they won't unless you are 
inheriting from it and then overloading the meta.

On Thursday, 30 January 2020 16:30:36 UTC, LBris wrote:
>
> I've never said it isn't saved in database. It is saved but in the table 
> of the employee since hrfleetemployee inherits from employee. It simply 
> adds this field to the table of Employee
>
> Le jeu. 30 janv. 2020 à 5:24 PM, Abhijeet Viswa  > a écrit :
>
>> How would the fields in HRFleetEmployee be persistent and linked to a 
>> particular Employee or Vehicle without being saved in the database? Or did 
>> I understand your code and request wrong? 
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAP1-YrrSo06-gxD1ZdzN0CCPQCm-shdah24H_ZVyLh_rGkU4%3DA%40mail.gmail.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/eed19926-f9e8-4eb8-b521-ce89b0745aca%40googlegroups.com.

Re: My proposal to create a new exception

[Steven Mapes]

Perhaps I'm totally missing the point and use case for this but is there 
any reason you are not simply using any of these

if expected_key is not in request.GET:
return MyErrorResponse(...)

if not request.GET.get("expected_key", None):
return MyErrorResponse(...)


required = ["one", "two", "three", "four"]
if not all(k in request.GET.keys() for k in required):
return MyErrorResponse(...)

I've used the latter approach if I have required parameters in a GET/POST 
and I'm not using forms. I  just adding the check to a base view and having 
required
be an attribute

On Sunday, 9 February 2020 05:15:01 UTC, Victor Porton wrote:
>
> In https://code.djangoproject.com/ticket/31239 I proposed to create 
> QueryDictKeyError derived from MultiValueDictKeyError and raise this 
> exception on a missing parameter in request.GET and request.POST.
>
> It is to be done to handle error in user data easily:
>
> try:
>  x = request.GET['x']
> except MultiValueDictError:
>  return response("Missing user data 'x'", status=404)
> try:
>  y = request.GET['y']
> except MultiValueDictError:
>  return response("Missing user data 'y'", status=404)
>
> is much more cumbersome and error-prone than:
>
> def handle_exception(self, exc):
>   if isinstance(exc, QueryDictKeyError):
> # It is an unwise assumption that this is necessarily missing HTTP 
> param,
> # but rewriting it in other way would be time consuming (and maybe 
> even more error prone).
> return MyErrorResponse({"code": "PAR_1", "message": "Missing param.", 
> "field": exc.args[0]})
>
> The latter may be added to a base view to handle such errors in the entire 
> project easily.
> This handle_exception() could be even integrated into the core of Dajngo 
> to handle such errors automatically without the user writing this code 
> manually repeatedly.
> Moreover, the above code is much more maintenable, as no need to change 
> error messages in each and every view, if a user wants to change the error 
> message.
>
> Programming is about automation and we need the task about handling user 
> input errors to be done automatically.
>
> @felixxm claims "Creating a single method to catch and handle all kind of 
> exceptions is error prone."
> But the reverse things is true: not handling exception automatically leads 
> to many code errors.
>
> @felixxm's claim as valid as "use CGI instead of Django: using a CMS is 
> error-prone, specify in the code exactly what you want rather to relying to 
> a single method."
> If code can be simplified, it needs to be simplified.
>
> Please support my feature request.
>

-- 
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/2423f3eb-e656-4084-a9c3-94e1ea41e969%40googlegroups.com.

Re: Deadlock bug in logging? Reproducible case

[Steven Mapes]

This is more an issue at the file system level and the hardware not being 
able to keep up rather than anything Django is doing.  It's the same 
fundamental principal for why you may turn off webserver logging to 
increase performance, writing to disk is expensive and so when dealing with 
high throughout you probably want to question why.

I've just run that on my laptop and hit your 1000 requests fine. I actually 
them bumped it up to run 6 requests per iteration and still was fine 
writing to disk. I started to have network resource issues when I bumped it 
up further but that was more limitations within chrome

In the real world if you were writing logs like this for information or 
debugging you would be best served to defer them by writing to a message 
queue of sort some, probably FIFO based as its logging, and then have as 
many subscribers as you want dealing with reading and processing those 
queued messages. This could be as few as one so that you never hit a 
deadlock or it could be a few, again it depends on the performance of the 
underlying hardware, what you are writing and where (database, disk, 
memory).


On Wednesday, 22 April 2020 18:23:31 UTC+1, Brian Tiemann wrote:
>
> Hi all,
>
> I was directed here after getting corroboration on #django and elsewhere.
>
> I have what appears to be a bug in which a Django app can deadlock if you 
> hit it with a lot (>3) of AJAX requests within a short time (i.e. all 
> triggered in parallel from a single HTML page). I have a reproducible case 
> here:
>
> https://github.com/data-graham/wedge
>
> I'd really appreciate it if someone could take a look and let me know 
> whether I'm doing something wrong, or if there's something systemic going 
> on. Thanks much!
>
>

-- 
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/1445d05d-eefc-43b1-8913-79d6e55de216%40googlegroups.com.

Re: Generate JWTs with Django

[Steven Mapes]

I completely agree with James. I felt dread when I saw a JWT Thread appear 
as, for me synonymous with flaws security and I'd rather Django stay well 
clear of them

On Monday, 27 April 2020 03:53:39 UTC+1, James Bennett wrote:
>
> On Sun, Apr 26, 2020 at 8:46 AM Adam Johnson > 
> wrote: 
> > 
> > James, I too would like to know your criticisms! I've always understood 
> that they aren't much different to signed cookies, but I haven't looked too 
> deeply at them. 
>
> Well, people asked. So. 
>
> The short summary is: JWT is over-complex, puts too much power in the 
> attacker's hands, has too many configuration knobs, and makes poor 
> cryptographic choices. This is why we see vulnerabilities in JWT 
> libraries and JWT-using systems again and again and again. 
>
> And even if you get every single bit of it right, in the ideal perfect 
> world with the ideal perfect implementation, the payoff is you've put 
> in a ton of work to get something that already existed: signed 
> cookies, for the use case of session identification, or any of several 
> better token or token-like systems -- everything from PASETO to just 
> timestamped HMAC'd values -- for the use case of inter-service 
> communication. 
>
> The longer version goes more like this... 
>
> JWT is a more complex thing than many people appreciate. In fact, it's 
> at least *five* things, each specified in its own RFC, plus some more 
> you have to know about and implement if you want any hope of getting 
> the actually-sorta-secure version. And right off the bat, that's 
> worrying: the more different things you have to implement, and the 
> more places you have to look to find out what and how to implement, 
> the more opportunities there are to make mistakes. 
>
> This complexity comes from the sheer number of different options JWT 
> tries to support, which in turn is an anti-pattern. JWTs may be 
> signed, or they may not. They may be encrypted, or they may not. There 
> are multiple different options for how to sign, how to encrypt, how to 
> manage and specify keys... in a well-designed system there would be 
> far fewer options. Ideally, there'd be only one option, and the 
> solution for a vulnerability being found in it would be to increment 
> the version of the underlying spec, and change to something 
> better. 
>
> Anyway. In JWT, signature and encryption schemes are effectively 
> negotiable, which is yet another anti-pattern: you are putting 
> enormous power in the hands of attackers to negotiate you down to a 
> bad, or nonexistent, cipher/algorithm for encryption or signing. TLS/SSL 
> learned this lesson the hard way; JWT has chosen not to learn it at 
> all. Worse, JWT embeds the negotiation about how to handle the token 
> into the token itself. This is just asking for trouble, and in fact 
> trouble has routinely occurred. As a somewhat sarcastic author of my 
> acquaintance put it: 
>
> > It is extraordinarily easy to screw up JWT. JWT is a JSON format 
> > where you have to parse and interpret a JSON document to figure out 
> > how to decrypt and authenticate a JSON document. It has revived bugs 
> > we thought long dead, like “repurposing asymmetric public keys as 
> > symmetric private keys”. 
>
> (from: https://latacora.micro.blog/a-childs-garden/) 
>
> More succinctly: JWTs inherently and unavoidably violate the 
> Cryptographic Doom Principle 
> (https://moxie.org/blog/the-cryptographic-doom-principle/). Worse, 
> JWTs put full control of the violation in the hands of the attacker, 
> who -- thanks to the high level of configurability JWT offers -- is 
> free to find the set of options most likely to compromise you, and 
> foist them on you. 
>
> That quoted line above about revived long-dead bugs is no joke, 
> incidentally. Here's one from a few years back: 
>
>
> https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ 
>
> Five different libraries, written in three different languages, all 
> had the same bug. I once had the misfortune of arguing with someone 
> who attributed this to the libraries being built by bad programmers, 
> or in bad languages. But I personally tend to agree with a line from 
> this talk: 
>
> https://www.okta.com/video/oktane19-cryptographic-wrong-answers/ 
>
> > Now you can say look those are all implementation vulnerabilities, 
> > it's not actually JWTs fault, I disagree. If I can find the same 
> > vulnerability in five popular libraries, then maybe the spec did a 
> > bad job of making sure people avoided that vulnerability. 
>
> So to completely head off the "it's just bad implementations" 
> argument, let's turn to the specs themselves: RFCs 7515, 7516, 7517, 
> 7518, and 7519 are the core specifications that make up with is 
> commonly called "JWT" (and in RFC-land is more properly called "JOSE" 
> -- "JSON Object Signing and Encryption", of which the token format is 
> but one part). 
>
> The JOSE RFCs make a number of choices regarding default sets of 
> stand

Re: Removing url() ?

[Steven Mapes]

This is the big thing for me which seems to be have been forgotten.

If you need to quickly upgrade a Django project from using url to re_path 
the fastest way with the least amount of code changes is to simply alias 
the import in your urls.py files I.E ```from django.urls import re_path as 
url``` then you won't have to update every individual entry. so I don't see 
this as a big deal and am in favour of completely removing it and continue 
to encourage people to not question why they are using re_path and not path 
anyway which is more secure and fits more common url usage.

Sure if you are going from 1.x up then you have to replace  more but you'll 
be making much larger changes anyway.



On Tuesday, 5 May 2020 19:13:30 UTC+1, James Bennett wrote:
>
> On Tue, May 5, 2020 at 9:45 AM ‫אורי‬‎ > 
> wrote:‬ 
> > My project contains about 100 calls to url() with regex. Can you explain 
> to me what has been changed and why, and how should I change my code to 
> stop using url()? And where is it documented? I checked the documentation 
> and I didn't find an explanation why url() was changed and what are the 
> differences between url() and path() and re_path()? 
>
> There is no difference; django.conf.urls.url() is just an alias for 
> django.urls.re_path(). 
>

-- 
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/0abf4520-a85a-431d-a6d6-58c98118958d%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Steven Mapes]

I also thought it was a taken more form HTTP rather than PHP but if this is 
changed please do not use *request.form_data* as that is also misleading as 
you can POST many more sources than form data such as with APIs. post_data 
would be much clearer.

On Tuesday, 5 May 2020 22:26:34 UTC+1, Adam Johnson wrote:
>
> request.GET and request.POST are misleadingly named:
>
>- GET contains the URL parameters and is therefore available whatever 
>the request method. This often confuses beginners and “returners” alike.
>- POST contains form data on POST requests, but not other kinds of 
>data from POST requests. It can confuse users who are posting JSON or 
> other 
>formats.
>
> Additionally both names can lead users to think e.g. "if request.GET:" 
> means "if this is a GET request", which is not true.
>
> I believe the CAPITALIZED naming style was inherited from PHP's global 
> variables $_GET, $_POST, $_FILES etc. ( 
> https://www.php.net/manual/en/reserved.variables.get.php ). It stands out 
> as unpythonic, since these are instance variables and not module-level 
> constants (as per PEP8 https://www.python.org/dev/peps/pep-0008/#constants 
> ).
>
> I therefore propose these renames:
>
>- request.GET -> request.query_params (to match Django Rest Framework 
>- see below)
>- request.POST -> request.form_data
>- request.FILES -> request.files
>- request.COOKIES -> request.cookies
>- request.META -> request.meta
>
> Since these are very core attributes and the change would cause a huge 
> amount of churn, I propose not deprecating the old aliases immediately, but 
> leaving them in with a documentation note that they "may be deprecated." 
> Perhaps they can be like url() or ifequal which came up on the mailing list 
> recently - put through the normal deprecation path after a few releases 
> with such a note.
>
> Django Rest Framework already aliases GET as request.query_params in its 
> request wrapper: 
> https://www.django-rest-framework.org/api-guide/requests/#query_params . 
> Therefore the name request.query_params should not be surprising. DRF also 
> provides request.data which combines request.POST and request.FILES, and 
> flexibly parses from different content types, but I'm not sure that's 
> feasible to implement in Django core.
>
> For reference, other Python web frameworks have more "Pythonic" naming:
>
>- Bottle: request.url_args, request.forms, request.files, 
>request.cookies, request.environ
>- Flask: request.args, request.form, request.files, request.cookies, 
>request.environ
>- Starlette: request.query_params, request.form(), 
>request.form()[field_name], request.cookies, scope
>
> One more note for those who might think such core attributes should be 
> left alone: Django 2.2 added request.headers as a way of accessing headers 
> by name. This is convenient as it avoids the need to transform the header 
> to the WSGI environ name. makes the code more readable, and in the process 
> reduces the potential for bugs. I believe this proposal is in the same vein.
>
>

-- 
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/3c6309ad-1af5-4c57-afa1-0c754143eb2f%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Steven Mapes]

Combined them would be very very bad and you would have the same problems 
as with $_REQUEST in PHP where you have to decide which one wins as you can 
make a POST to a URL with querystring where one of the parameters uses the 
same name as a element of the POST and but where the value is different. 
It's bad practice but it's valid


On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote:
>
> I agree. If anything, I've always had issues with GET & POST being 
> different entities in the first place, but never with their names. I would 
> really like to see an entity combining both of them. THAT one, maybe the 
> preferred way of doing so, would be lowercase, but RAW representations of 
> incoming data, I for one like them being upper case. Always makes me think 
> twice before playing with them.
>
> The content negotiation thingy is also something I would like to see more 
> time invested in: I have a project where I have to hack & slash DRF's 
> implementation in order to get what I want, but perhaps I'm tackling the 
> issue incorrectly. But that's beside the point. People will always try to 
> do stuff framework developers didn't think of. What's important is to give 
> them a platform where they can do so easily.
>
> LP,
> Jure
> On 06/05/2020 08:08, Carlton Gibson wrote:
>
> Hmmm. I have to say I think there are areas where we could get a better 
> ROI on our time than this. 
>
> I always took the capitalisation of GET &co to come from HTTP 
>  — I'd say that's where PHP 
> took it from too but 🤷‍♀️
> That they're a bit "unpythonic" (Meh™) is OK: they serve to remind that 
> request was ultimately mapped from an HTTP request, and most of that is 
> still available if you care to dig. 
>
>  
>
> Then request.form_data -> Oh, where's my form data, if not in "form_data"? 
> Well it's in "query_params"... Hmmm
> That's no better learning experience. Folks still have to learn how HTTP 
> maps to request properties. 
>
> > ... better ROI... 
>
> There's lots we might take from DRF. The one that's come up before, and 
> which for work was began, but only began, was content negotiation. 
> I'd rather see work/energy/effort spent there. 
>
> Maybe we'd have different names if we began today. But this would be very 
> disruptive. 
> We've just had a discussion re url() suggesting that "deprecated but not 
> really" is an error on our part, and having two ways to do things 
> definitely isn't "pythonic". 
> So I'm inclined towards the range between -1 and -0 — but I haven't had my 
> coffee yet. 😝
>
> Kind Regards,
>
> Carlton 
>
>> -- 
> 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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/bc60e809-6390-44fc-a07a-ed6e0f9eef86%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/b23d3b4a-9ff4-42ed-a08b-594f185b8d3b%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Steven Mapes]

Ah yes that's true, totally forgot about request.body just then even though I 
was using it a few days ago. So yes renaming it would help in that regard as I 
do remember seeing a few S/O question where it's confused people in the past.

Mr Steven Mapes
Software Development and Solutions

E: st...@jigsawtech.co.uk (mailto:st...@jigsawtech.co.uk)
P: 07974220046 (tel:07974220046)
W: https://uk.linkedin.com/in/stevemapes/

This E-Mail and its contents are confidential, protected by law and legally 
privileged. Only access by the addressee is authorised. Any liability (in 
negligence, contract or otherwise) arising from any third party taking any 
action or refraining from taking any action on the basis of any of the 
information contained in this E-Mail is hereby excluded to the fullest extent 
of the law. In the event that you are not the addressee, please notify the 
sender immediately. Do not discuss, disclose the contents to any person or 
store or copy the information in any medium or use it for any purpose 
whatsoever.

On May 6 2020, at 9:43 am, Adam Johnson  wrote:
> > I always took the capitalisation of GET &co to come from HTTP 
> > (https://tools.ietf.org/html/rfc2616#page-36) — I'd say that's where PHP 
> > took it from too but 🤷‍♀️
> >
>
>
> Yes GET and POST are capitalized in HTTP, but then COOKIES is not (Set-Cookie 
> / Cookies headers), and FILES and META aren't direct references to anything 
> in HTTP.
>
> Also I'm not sure it's a particularly good argument. Capitalization inside 
> Python should be based upon the conventions of Python, not the conventions of 
> the system the code talks to. For example, we have SELECT ... FOR UPDATE in 
> SQL, but .select_for_update() in the ORM.
>
> > Hmmm. I have to say I think there are areas where we could get a better ROI 
> > on our time than this.
>
>
> I think if we took the amount of time spent by users due to the confusion of 
> GET/POST, divided by the amount of time to make the code and docs changes, it 
> would come out with a relatively good ratio.
>
> My inspiration (or "the final straw") for making this proposal was a recent 
> forum question with confusion on the meaning of POST: 
> https://forum.djangoproject.com/t/ajax-post-to-view-not-displaying-content/2034
>  . I'm pretty sure I saw another one in the past month but can't find it But 
> it's an issue I've seen repeatedly. I know I've even spent time figuring out 
> how I'd get the query params during a POST request.
>
> > please do not use request.form_data as that is also misleading as you can 
> > POST many more sources than form data such as with APIs. post_data would be 
> > much clearer.
>
> Steven - I think you're confused by the current name. request.POST *only* 
> contains POST'd form data. It does not contain other POST'd data, such as 
> JSON bodies. So perahps that's another point for the name change?
> On Wed, 6 May 2020 at 09:29, Steven Mapes  (mailto:st...@jigsawtech.co.uk)> wrote:
> > Combined them would be very very bad and you would have the same problems 
> > as with $_REQUEST in PHP where you have to decide which one wins as you can 
> > make a POST to a URL with querystring where one of the parameters uses the 
> > same name as a element of the POST and but where the value is different. 
> > It's bad practice but it's valid
> >
> >
> > On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote:
> > > I agree. If anything, I've always had issues with GET & POST being 
> > > different entities in the first place, but never with their names. I 
> > > would really like to see an entity combining both of them. THAT one, 
> > > maybe the preferred way of doing so, would be lowercase, but RAW 
> > > representations of incoming data, I for one like them being upper case. 
> > > Always makes me think twice before playing with them.
> > >
> > >
> > > The content negotiation thingy is also something I would like to see more 
> > > time invested in: I have a project where I have to hack & slash DRF's 
> > > implementation in order to get what I want, but perhaps I'm tackling the 
> > > issue incorrectly. But that's beside the point. People will always try to 
> > > do stuff framework developers didn't think of. What's important is to 
> > > give them a platform where they can do so easily.
> > > LP,
> > > Jure
> > >
> > >
> > > On 06/05/2020 08:08, Carlton Gibson wrote:
> > > > Hmmm. I have to say I think there are areas where we could get a better 
> >

Re: Proposal on how add configuration options to Email Backends

[Steven Mapes]

I have clients that use different mailboxes sometimes with totally different 
providers (O365, Google, their own mailservers) so they need different SMTP 
settings. In some cases they also read from the mailboxes, granted this isn't 
from Django builtin functionality but in those cases it uses the same 
credentials.

Steve Mapes
Steven Mapes T/A Jigsaw Tech

E: st...@jigsawtech.co.uk 
(https://link.getmailspring.com/link/e32a2c46-7b3e-441e-ab1b-879d066cf...@getmailspring.com/0?redirect=mailto%3Asteve%40jigsawtech.co.uk&recipient=ZGphbmdvLWRldmVsb3BlcnNAZ29vZ2xlZ3JvdXBzLmNvbQ%3D%3D)
P: +44(0)7974220046 (tel:+44(0)7974220046)
W: https://www.jigsawtech.co.uk/ 
(https://link.getmailspring.com/link/e32a2c46-7b3e-441e-ab1b-879d066cf...@getmailspring.com/1?redirect=https%3A%2F%2Fwww.jigsawtech.co.uk%2F&recipient=ZGphbmdvLWRldmVsb3BlcnNAZ29vZ2xlZ3JvdXBzLmNvbQ%3D%3D)

The entire content of this email message is confidential. This also applies to 
any files attached to it. This email is intended for an individual or entity to 
whom they are addressed. In case you are not the addressee of this email, and 
you have received it in error, contact the system manager immediately. The 
information could be very sensitive, and it is intended for the specific 
addressee. This email should not be disseminated, distributed or copied. If you 
have received this email and it was not for you, please notify the sender by 
email immediately and afterward delete this email from your system. Disclosing, 
copying, distributing, or taking any action in reliance on the email content is 
strictly prohibited.

On Jan 30 2022, at 3:38 pm, Florian Apolloner  wrote:
> I do not understand why you would need multiple email backends to send from 
> different addresses. Can you elaborate on that?
>
> On Sunday, January 30, 2022 at 1:18:48 PM UTC+1 st...@jigsawtech.co.uk wrote:
> > I've a big +1 on changing email config to a dictionary to support multiple 
> > backends as it's very much a common occurrence for both clients of mine and 
> > for my own businesses. Most of the use cases are when they main site sends 
> > emails from no-reply@ such as for password resets but then when alternative 
> > email are required for sales and/or customer service email address where 
> > it's handled via the website. Currently I end up creating a custom 
> > settings.py dictionary to store the settings so I can then refer to that 
> > using the connection for swapping the backend to send from.
> >
> > On Sunday, 30 January 2022 at 11:14:54 UTC f.apo...@gmail.com wrote:
> > > Hi Jacob,
> > >
> > > I wouldn't be opposed to move email configuration into a dictionary 
> > > (somewhere between -0 and +0). Although if we plan to do that we should 
> > > rethink all the existing session variables and other as well I guess and 
> > > figure out if we should move more settings to dictionaries.
> > >
> > > > why shouldn't it makes sense to have different email backends? If you 
> > > > have a staging system you may want to use you local SMTP-relay, while 
> > > > in production
> > > you may for instance use AWSs SES 
> > > (https://docs.aws.amazon.com/ses/latest/dg/Welcome.html) service.
> > >
> > > This specific example at hand is imo not a good motivator to add support 
> > > for multiple backends because the settings would imo be different. Take 
> > > databases as an example: You also don't have staging/production in there 
> > > but switch the actual values in the default database.
> > >
> > > > `EMAIL = [...]`
> > >
> > > I am not sure a list makes sense here and would go for similarity with 
> > > CACHES & DATABASES since you'd usually identify the backend via a unique 
> > > name or so. Also DATABASES & CACHES have an OPTIONS dict which is the 
> > > passed on to the backend, I think we should follow suit here.
> > >
> > > > Personally, I would prefer SMTP = {...}
> > >
> > > I do not think SMTP would be a good fit because many services allow HTTP 
> > > submission, so what we are sending is actually an email and smtp is just 
> > > a protocol implementation in the backend of AWS SES or so.
> > >
> > > As for other email backends that do require different options: I do not 
> > > see an issue when they simply take `EMAIL_AWS_SES_KEY` and document it as 
> > > such; this doesn't require us to add more flexibility to email backends…
> > >
> > > So I guess it boils down to the following questions:
> > >
> > > * Do we want to support multiple (at the same time) email backends, if 

Re: Proposal on how add configuration options to Email Backends

[Steven Mapes]

I should add I also have other instances my clients use a custom AWS SES 
backend I wrote used for various types of sends (bulk, newsletters) but 
generally sends where they need SNS notifications to trigger HTTPS postbacks 
for certain results from the send such as bounced mails, spam reports etc where 
those the requests go back to the django server to be handled whereas other 
mail sends may go via O365 / Google for general, often internal, notifications 
and emails send.

I have another client who has two mail providers where one is the primary and 
if that fails due to the SMTP server being down, the platform othen fails over 
to re-send via the backup SMTP server.
Steve Mapes
Steven Mapes T/A Jigsaw Tech

E: st...@jigsawtech.co.uk 
(https://link.getmailspring.com/link/cf847694-1156-4ba3-bc92-5f42d434b...@getmailspring.com/0?redirect=mailto%3Asteve%40jigsawtech.co.uk&recipient=ZGphbmdvLWRldmVsb3BlcnNAZ29vZ2xlZ3JvdXBzLmNvbQ%3D%3D)
P: +44(0)7974220046 (tel:+44(0)7974220046)
W: https://www.jigsawtech.co.uk/ 
(https://link.getmailspring.com/link/cf847694-1156-4ba3-bc92-5f42d434b...@getmailspring.com/1?redirect=https%3A%2F%2Fwww.jigsawtech.co.uk%2F&recipient=ZGphbmdvLWRldmVsb3BlcnNAZ29vZ2xlZ3JvdXBzLmNvbQ%3D%3D)

The entire content of this email message is confidential. This also applies to 
any files attached to it. This email is intended for an individual or entity to 
whom they are addressed. In case you are not the addressee of this email, and 
you have received it in error, contact the system manager immediately. The 
information could be very sensitive, and it is intended for the specific 
addressee. This email should not be disseminated, distributed or copied. If you 
have received this email and it was not for you, please notify the sender by 
email immediately and afterward delete this email from your system. Disclosing, 
copying, distributing, or taking any action in reliance on the email content is 
strictly prohibited.

On Jan 30 2022, at 3:38 pm, Florian Apolloner  wrote:
> I do not understand why you would need multiple email backends to send from 
> different addresses. Can you elaborate on that?
>
> On Sunday, January 30, 2022 at 1:18:48 PM UTC+1 st...@jigsawtech.co.uk wrote:
> > I've a big +1 on changing email config to a dictionary to support multiple 
> > backends as it's very much a common occurrence for both clients of mine and 
> > for my own businesses. Most of the use cases are when they main site sends 
> > emails from no-reply@ such as for password resets but then when alternative 
> > email are required for sales and/or customer service email address where 
> > it's handled via the website. Currently I end up creating a custom 
> > settings.py dictionary to store the settings so I can then refer to that 
> > using the connection for swapping the backend to send from.
> >
> > On Sunday, 30 January 2022 at 11:14:54 UTC f.apo...@gmail.com wrote:
> > > Hi Jacob,
> > >
> > > I wouldn't be opposed to move email configuration into a dictionary 
> > > (somewhere between -0 and +0). Although if we plan to do that we should 
> > > rethink all the existing session variables and other as well I guess and 
> > > figure out if we should move more settings to dictionaries.
> > >
> > > > why shouldn't it makes sense to have different email backends? If you 
> > > > have a staging system you may want to use you local SMTP-relay, while 
> > > > in production
> > > you may for instance use AWSs SES 
> > > (https://docs.aws.amazon.com/ses/latest/dg/Welcome.html) service.
> > >
> > > This specific example at hand is imo not a good motivator to add support 
> > > for multiple backends because the settings would imo be different. Take 
> > > databases as an example: You also don't have staging/production in there 
> > > but switch the actual values in the default database.
> > >
> > > > `EMAIL = [...]`
> > >
> > > I am not sure a list makes sense here and would go for similarity with 
> > > CACHES & DATABASES since you'd usually identify the backend via a unique 
> > > name or so. Also DATABASES & CACHES have an OPTIONS dict which is the 
> > > passed on to the backend, I think we should follow suit here.
> > >
> > > > Personally, I would prefer SMTP = {...}
> > >
> > > I do not think SMTP would be a good fit because many services allow HTTP 
> > > submission, so what we are sending is actually an email and smtp is just 
> > > a protocol implementation in the backend of AWS SES or so.
> > >
> > > As for other email backends that do require different options: I do not 
> >