Re: Decision on a 2FA PR

[Carlton Gibson]

Hi Yonas. 

Thanks for your input here. 

Two points:  

   - I *think* one reason Django doesn't already have 2fa itself is that 
   available methods have (up to now) each been problematic in their own way. 
   The trouble with adding a sub-optimal approach into Django is that we're 
   essentially stuck with it forever. We can't realistically add an option, 
   have it widely adopted and then say, "Oh, actually, we're deprecating this, 
   use New Hotness™ instead" — that's not what folks use Django for. So, when 
   this has come up before, the answer has generally been to keep 
   implementations in third-party packages, of which there are several 
   options. 
   - It *looks* like WebAuthn (and the whole Fido Alliance grouping 
   ) is the way forward now. Per-device keys, 
   stored in secure enclaves, with biometric authentication, and OS-level and 
   password manager app-level integrations, etc. **This** is what we should be 
   integrating no? (This is a solution, finally we can agree is robust enough 
   no?)

Maybe either of those points are wrong but, I'd rather see effort going 
into "What does WebAuthn in Django look like?" — answering that would be a 
major contribution. 

Kind Regards,

Carlton



On Sunday, 5 June 2022 at 19:48:22 UTC+2 Yonas wrote:

> Hi,
>
> In light of what happened to the ctx package, this is a good time to get a 
> conclusion on the following topic.
>
> I opened a PR  based on an 
> accepted ticket  and a 
> discussion . 
> The PR implements 2fa but excludes WebAuthn, leaving it out as an 
> alternative to Django password-based auth. But an idea on GitHub was 
> forwarded that the PR won’t be accepted without at least supporting 
> WebAuthn.
>
> While 2fa is one use case of WebAuthn, the primary use case, in my 
> opinion, is providing an alternative to or a replacement for password-based 
> authentication. Regardless of its use case, the implementation of WebAuthn 
> does not have a lot in common with the opened PR. 
>
> Instead of taking the all-or-nothing approach, doesn’t it make more sense 
> to work on the opened PR--making Django more secure--and support WebAuthn 
> when someone in the future opens a PR for either or both of the use cases?
>
> Thanks!
>

-- 
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/898b0499-d201-47a7-8bfd-4d026aeeafbbn%40googlegroups.com.

Re: Feature Idea: Allow setting session cookie name dynamically

[Florian Apolloner]

Hi Maciej,

You can already customize the cookie name via a setting. What this request 
is asking is customization based on the request object which is not that 
common. Did you check that you configured your applications correctly to 
use different cookie names 
(https://docs.djangoproject.com/en/4.0/ref/settings/#session-cookie-name)?

> I wonder if using a Django project code name as part of session cookie 
for new projects would have a potential to be considered as an accepted 
feature.

has not been considered (as far as I know) and is something I'd be strongly 
against.

Cheers,
Florian

On Monday, June 6, 2022 at 11:51:24 PM UTC+2 macie...@gmail.com wrote:

> Hi Dan and Carlton,
>
> In my current company I am impacted by conflicting session cookie name. We 
> have several internal tools built on Django, available in the internal 
> network under the same top-level domain. The scope of session cookies 
> apparently was set on more than one service to a wildcard. Majority of 
> users use only one of services in day-to-day work, so it's not impacting a 
> big number of people.
>
> I personally would be +1 for exposing a method to easily and without 
> copying much code one was able to change it.
>
> I wonder if using a Django project code name as part of session cookie for 
> new projects would have a potential to be considered as an accepted feature.
>
> Kind regards,
> Maciej
>
> pon., 6 cze 2022 o 22:19 Dan Strokirk  napisał(a):
>
>> Hi Carlton, thanks for the response.
>>
>> An external package might be useful, although the code majority of the 
>> code would be the copied SessionMiddleware code and the tiny changes to 
>> allow a dynamic cookie name, so my thoughts is that this might be "too 
>> small" for a published pypi package?
>>
>> But since I haven't found a similar request earlier on this mailing list 
>> or the issue tracker, it seems that it might be really niche, as you say!
>>
>> Best regards,
>> Dan
>>
>> -- 
>> 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/01a91019-8d54-4322-a295-dbfdc12dfab9n%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/08a438ff-9d7a-47e0-abe2-d68a7dd20935n%40googlegroups.com.

Re: Supporting Oracle's renamed cx_Oracle driver in Django

[Christopher Jones]

> I agree with Florian, I'd prefer adding support for *python-oracledb* in 
Django 4.1 and immediately deprecate using *cx_Oracle *(will be removed in 
Django 5.0).

That sounds fair.  The cx_Oracle namespace won't have any substantive 
changes; maybe some new wheels for Python 3.11, and any critical bug 
fixes.  All progress will be under the new name.

The question is how to add support cleanly so that both names are supported 
in 4.1?  Is there a preference?  Particularly how can it be be done to 
reuse code without (temporary) duplication?

Regarding connection options, yes some things are supported with the Easy 
Connect Plus syntax.  There are some connection properties that aren't 
supported, e.g  application contexts (this was also true of cx_Oracle). And 
maybe more in future depending what users ask for. A generic way to set 
these, e.g with OPTIONS is a good direction.  

Chris

On Tuesday, May 31, 2022 at 7:04:07 PM UTC+10 Mariusz Felisiak wrote:

> I agree with Florian, I'd prefer adding support for *python-oracledb* in 
> Django 4.1 and immediately deprecate using *cx_Oracle *(will be removed 
> in Django 5.0).
>
> *3. Supporting some new connection parameters and using service names 
>>> instead of SIDs*
>>>
>>> One new feature of the python-oracledb driver are additional connect() 
>>> keyword arguments like hostname, port, service_name, tcp_connect_timeout.  
>>> (The makedsn() function is now deprecated in python-oracle because of 
>>> this change.)  How can new parameters best be passed to python-oracledb?
>>>
>>
> As far as I'm aware this is already supported with an easy connect string 
> or full DSN in *NAME*, see docs 
> 
> .
>
> Best,
> Mariusz
>
>

-- 
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/6f449d19-8560-4f29-8eb9-61e5aea63b45n%40googlegroups.com.

Re: Supporting Oracle's renamed cx_Oracle driver in Django

[Florian Apolloner]

Hi Chris,

On Tuesday, June 7, 2022 at 11:30:46 AM UTC+2 christopher@gmail.com 
wrote:

> The question is how to add support cleanly so that both names are 
> supported in 4.1?  Is there a preference?  Particularly how can it be be 
> done to reuse code without (temporary) duplication?
>

Good question, no idea :) I am having the same problem with psycopg3 and 
this is what I did 
https://github.com/django/django/pull/15687/files#diff-01f6880f77beca32ee83e011072ba73dc7eed7f9f3efdebd935af693a4fac7b3
 
-- basically I added a compatibility module which does imports from the 
respective locations, with the idea of being able to simply run sed over 
this in the future. I know this isn't much of an answer and the differences 
between psycopg2 & 3 are rather minimal but maybe a similar approach is 
viable for oracle as well?
 

> Regarding connection options, yes some things are supported with the Easy 
> Connect Plus syntax.  There are some connection properties that aren't 
> supported, e.g  application contexts (this was also true of cx_Oracle). And 
> maybe more in future depending what users ask for. A generic way to set 
> these, e.g with OPTIONS is a good direction.  
>

Yes, I'd use the existing backends as guidelines, common stuff like HOST 
etc fits into the toplevel imo.

Cheers,
Florian

-- 
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/8f4fb80c-b0b6-4125-9816-f31651d55c9dn%40googlegroups.com.

Re: Feature Idea: Allow setting session cookie name dynamically

[Maciek Olko]

Ah, thank you for explaining. I missed the point and the existing setting,
sorry.

Cheers,
Maciej

wt., 7 cze 2022 o 11:26 Florian Apolloner 
napisał(a):

> Hi Maciej,
>
> You can already customize the cookie name via a setting. What this request
> is asking is customization based on the request object which is not that
> common. Did you check that you configured your applications correctly to
> use different cookie names (
> https://docs.djangoproject.com/en/4.0/ref/settings/#session-cookie-name)?
>
> > I wonder if using a Django project code name as part of session cookie
> for new projects would have a potential to be considered as an accepted
> feature.
>
> has not been considered (as far as I know) and is something I'd be
> strongly against.
>
> Cheers,
> Florian
>
> On Monday, June 6, 2022 at 11:51:24 PM UTC+2 macie...@gmail.com wrote:
>
>> Hi Dan and Carlton,
>>
>> In my current company I am impacted by conflicting session cookie name.
>> We have several internal tools built on Django, available in the internal
>> network under the same top-level domain. The scope of session cookies
>> apparently was set on more than one service to a wildcard. Majority of
>> users use only one of services in day-to-day work, so it's not impacting a
>> big number of people.
>>
>> I personally would be +1 for exposing a method to easily and without
>> copying much code one was able to change it.
>>
>> I wonder if using a Django project code name as part of session cookie
>> for new projects would have a potential to be considered as an accepted
>> feature.
>>
>> Kind regards,
>> Maciej
>>
>> pon., 6 cze 2022 o 22:19 Dan Strokirk  napisał(a):
>>
>>> Hi Carlton, thanks for the response.
>>>
>>> An external package might be useful, although the code majority of the
>>> code would be the copied SessionMiddleware code and the tiny changes to
>>> allow a dynamic cookie name, so my thoughts is that this might be "too
>>> small" for a published pypi package?
>>>
>>> But since I haven't found a similar request earlier on this mailing list
>>> or the issue tracker, it seems that it might be really niche, as you say!
>>>
>>> Best regards,
>>> Dan
>>>
>>> --
>>> 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/01a91019-8d54-4322-a295-dbfdc12dfab9n%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/08a438ff-9d7a-47e0-abe2-d68a7dd20935n%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/CALYYG80d1ngzzxCOJs3-M494BGLssVGRMgmQEUWopFGeXXghoQ%40mail.gmail.com.

Re: Decision on a 2FA PR

[Yonas]

Hi, Carlton!

Thanks for getting back to me.

How difficult is it to introduce new 2fa options without deprecating the 
existing ones if the right design is in place? I do not expect it to be 
challenging. But one downside, among others, would be the maintenance 
burden.

Correct me if I am wrong, but for a while now, some of the widely popular 
2fa options are SMS, email, TOTP, and u2f (which no longer has an API in 
Google Chrome). There are not a lot of new additions to the list that are 
getting momentum except WebAuthn. The point is, it should be okay to choose 
one or two 2fa options and keep them.

Having said that, the responses from some of the community members seem to 
give a conclusion for the PR.

Regarding 2fa as a third-party package, reconsidering that would be good. 
While Django helps users choose a strong password, many compromised 
passwords meet regulatory requirements. Django (a battery included 
framework), developers, and users will immensely benefit from having a 
built-in 2fa.

Moving forward, seeing the role of WebAuthn in Django is interesting. It 
can serve as 2fa, an alternative to Django auth, or both. I think this is 
good enough to start the conversation.

On Tuesday, June 7, 2022 at 11:06:41 AM UTC+3 carlton...@gmail.com wrote:

> Hi Yonas. 
>
> Thanks for your input here. 
>
> Two points:  
>
>- I *think* one reason Django doesn't already have 2fa itself is that 
>available methods have (up to now) each been problematic in their own way. 
>The trouble with adding a sub-optimal approach into Django is that we're 
>essentially stuck with it forever. We can't realistically add an option, 
>have it widely adopted and then say, "Oh, actually, we're deprecating 
> this, 
>use New Hotness™ instead" — that's not what folks use Django for. So, when 
>this has come up before, the answer has generally been to keep 
>implementations in third-party packages, of which there are several 
>options. 
>- It *looks* like WebAuthn (and the whole Fido Alliance grouping 
>) is the way forward now. Per-device keys, 
>stored in secure enclaves, with biometric authentication, and OS-level and 
>password manager app-level integrations, etc. **This** is what we should 
> be 
>integrating no? (This is a solution, finally we can agree is robust enough 
>no?)
>
> Maybe either of those points are wrong but, I'd rather see effort going 
> into "What does WebAuthn in Django look like?" — answering that would be a 
> major contribution. 
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sunday, 5 June 2022 at 19:48:22 UTC+2 Yonas wrote:
>
>> Hi,
>>
>> In light of what happened to the ctx package, this is a good time to get 
>> a conclusion on the following topic.
>>
>> I opened a PR  based on an 
>> accepted ticket  and a 
>> discussion . 
>> The PR implements 2fa but excludes WebAuthn, leaving it out as an 
>> alternative to Django password-based auth. But an idea on GitHub was 
>> forwarded that the PR won’t be accepted without at least supporting 
>> WebAuthn.
>>
>> While 2fa is one use case of WebAuthn, the primary use case, in my 
>> opinion, is providing an alternative to or a replacement for password-based 
>> authentication. Regardless of its use case, the implementation of WebAuthn 
>> does not have a lot in common with the opened PR. 
>>
>> Instead of taking the all-or-nothing approach, doesn’t it make more sense 
>> to work on the opened PR--making Django more secure--and support WebAuthn 
>> when someone in the future opens a PR for either or both of the use cases?
>>
>> Thanks!
>>
>

-- 
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/4656a44d-c993-44df-a7b6-b0bf7658b9a8n%40googlegroups.com.

Re: Decision on a 2FA PR

[Yonas]

Hi,

Thanks for getting back to me.

How difficult is it to introduce new 2fa options without deprecating the 
existing ones if the right design is in place? I do not expect it to be 
challenging. But one downside, among others, would be the maintenance 
burden.

Correct me if I am wrong, but for a while now, some of the widely popular 
2fa options are SMS, email, TOTP, and u2f (which no longer has an API in 
Google Chrome). There are not a lot of new additions to the list that are 
getting momentum except WebAuthn. The point is, it should be okay to choose 
one or two 2fa options and keep them.

Having said that, the responses from some of the community members seem to 
give a conclusion for the PR.

Regarding 2fa as a third-party package, reconsidering that would be good. 
While Django helps users choose a strong password, many compromised 
passwords meet regulatory requirements. Django (a batteries-included 
framework), developers, and users will immensely benefit from having a 
built-in 2fa.

Moving on, seeing the role of WebAuthn in Django is interesting. It can 
serve as 2fa, an alternative to Django auth, or both. I think this is good 
enough to start the conversation.

On Tuesday, June 7, 2022 at 11:06:41 AM UTC+3 carlton...@gmail.com wrote:

> Hi Yonas. 
>
> Thanks for your input here. 
>
> Two points:  
>
>- I *think* one reason Django doesn't already have 2fa itself is that 
>available methods have (up to now) each been problematic in their own way. 
>The trouble with adding a sub-optimal approach into Django is that we're 
>essentially stuck with it forever. We can't realistically add an option, 
>have it widely adopted and then say, "Oh, actually, we're deprecating 
> this, 
>use New Hotness™ instead" — that's not what folks use Django for. So, when 
>this has come up before, the answer has generally been to keep 
>implementations in third-party packages, of which there are several 
>options. 
>- It *looks* like WebAuthn (and the whole Fido Alliance grouping 
>) is the way forward now. Per-device keys, 
>stored in secure enclaves, with biometric authentication, and OS-level and 
>password manager app-level integrations, etc. **This** is what we should 
> be 
>integrating no? (This is a solution, finally we can agree is robust enough 
>no?)
>
> Maybe either of those points are wrong but, I'd rather see effort going 
> into "What does WebAuthn in Django look like?" — answering that would be a 
> major contribution. 
>
> Kind Regards,
>
> Carlton
>
>
>
> On Sunday, 5 June 2022 at 19:48:22 UTC+2 Yonas wrote:
>
>> Hi,
>>
>> In light of what happened to the ctx package, this is a good time to get 
>> a conclusion on the following topic.
>>
>> I opened a PR  based on an 
>> accepted ticket  and a 
>> discussion . 
>> The PR implements 2fa but excludes WebAuthn, leaving it out as an 
>> alternative to Django password-based auth. But an idea on GitHub was 
>> forwarded that the PR won’t be accepted without at least supporting 
>> WebAuthn.
>>
>> While 2fa is one use case of WebAuthn, the primary use case, in my 
>> opinion, is providing an alternative to or a replacement for password-based 
>> authentication. Regardless of its use case, the implementation of WebAuthn 
>> does not have a lot in common with the opened PR. 
>>
>> Instead of taking the all-or-nothing approach, doesn’t it make more sense 
>> to work on the opened PR--making Django more secure--and support WebAuthn 
>> when someone in the future opens a PR for either or both of the use cases?
>>
>> Thanks!
>>
>

-- 
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/06d07367-93dc-4b44-b04b-cd7fd899d77fn%40googlegroups.com.

Re: bulk_update() support for unique fields instead of only primary key

[Ebram Shehata]

Thank you for your reply.

> Implementation might get complicated in multi table
> inheritance, where the unqiue field may not reside on the target table
> itself (would need a similar tables+rows lookup expansion as done for pk).

How can it be complicated ? I thought it's just something like 
getattr(MyModel, field_name) to get value and
model._meta.get_field(unique_field) to get the field instance..
Where can I find explanation for what you mean? and where can I find the PK 
code you're referring to?

> Overall this sounds like a valuable API addition to bulk_update

Thank you. I was asked to re-open the ticket if there's an agreement to add 
the update..
Should I re-open it or we will need more than one person to agree on the 
update ?
(I'm sorry, this is my first contribution)
On Tuesday, June 7, 2022 at 8:03:13 AM UTC+2 j.bre...@netzkolchose.de wrote:

> Imho the pk field being treated special by bulk_update (as the only 
> record filter predicate, non updatable) comes from one simple idea - 
> stable object identity during the updates. For an ORM proper object 
> identification is rather important to not mix things up, shifting 
> identities might create havoc further down the road or in internal code, 
> if it is not prepared to deal with identity shifts. Whether stable 
> identities are really needed for bulk_update or could be lifted by 
> making pk updatable I cannot tell for sure.
>
> About record identification by another unique field - imho that should 
> be safe as long as the unique field can sufficiently identify rows in 
> question on a table. Implementation might get complicated in multi table 
> inheritance, where the unqiue field may not reside on the target table 
> itself (would need a similar tables+rows lookup expansion as done for pk).
> Overall this sounds like a valuable API addition to bulk_update, whether 
> it ultimately could lift the non updatable state of pk itself, remains 
> uncertain (prolly needs tons of tests and a serious code review of some 
> internals).
>
> Cheers,
> jerch
>
> NB: Btw fetching proper pks upfront from some other unique field is 
> typically very cheap compared to bulk_update runtime itself, given you 
> have indexed those columns.
>
>
> Am 07.06.22 um 02:15 schrieb Ebram Shehata:
> > I've already created a ticket that ended up with 'WONTFIX' here 
> > .
> > Please read it first.
> > 
> > The scenario that led me trying to add that feature:
> > Well, I'v a model that has a primary key and unique field...
> > Every  X period of time I've a cron that calls an external API to load 
> > updated data and store it in my Django project db.
> > Thing is I want to execute the update query without having to have the 
> > pk with me.. I already have the unique field in hand (got it from the 
> > API) and it should be enough to identify what object to be updated..
> > 
> > example code that will do so..
> > 
> > /# call external API and load data as list[dict]/
> > /objs = list()/
> > /for record in data:/
> > /# Just create instance of MyModel class with values needed../
> > /objs.append(MyModel(my_unique_field=data['national_id'], name="New 
> > Name"))/
> > /# I expect to do:
> > MyModel.objects.bulk_update(objs, fields=["name"], 
> > unique_field="my_unique_field")/
> > 
> > The current implementation requires every object to have its primary key 
> > set, but, that's not always the case. Also, if the primary key is 
> > my-django-project-generated, there's no way AFAIK to get those PKs 
> > without having to query them from DB, which will be a very expensive 
> > query to run if the data is large.
> > 
> > You can find the POC PR here: 
> https://github.com/django/django/pull/15764
> > 
> > I really thing that'd be a very useful update to add.
> > 
> > I also have a question about this function: We can't use it to update 
> > primary keys.. I'm wondering why ? I want to also add that support to it.
> > 
> > -- 
> > 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/f532b4fd-aba6-44dd-b373-e6e934ff8b67n%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/django-developers/f532b4fd-aba6-44dd-b373-e6e934ff8b67n%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