Add YugabyteDB backend to the Django documentation

['Sfurti Sarah' via Django developers (Contributions to Django itself)]

Hello,

We at YugabyteDB have implemented a backend for Django that allow users to 
use Django with YugabyteDB better. We would love to get listed on here 

 with 
the other 3rd party backends. Our backend package is available here 
 on github and published on Pypi as 
well. Please let us know the procedure to be followed to get listed. 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/0563eff8-5f30-4dab-b3ac-e66b38a937c6n%40googlegroups.com.

[Proposal] Add a PR template to the Django repo

[Sarah Boyce]

Hi all,

Wondering if I could get some consensus at to whether a PR template would 
be beneficial to the Django GitHub repository.

What I have in mind, would be pulling elements from the patch review 
checklist[1] to be an actual checklist[2] (perhaps in a collapsed 
section[3]) that appears on the PR itself.

Reasons I think it's not a good idea:
- we would be duplicating information in 2 places (in the docs and in the 
PR template), which would be harder to maintain.
- when creating your first PR, a comment asks you to review this checklist 
(links to the docs). So people without this comment have done it before and 
presumably read it.

Reasons I think it's a good idea:
- brings the information needed closer to the pr author, without linking 
them away
- I had "read" the checklist, and have since re-read, and there was a lot I 
hadn't taken in. I think it is still useful for after the first patch.
- I like to cross things off lists

I am on the fence as to whether it would add value or not. If we think it 
would add value, I would be happy to create a ticket in Track and raise a 
PR.

Looking forward to hearing your thoughts.
Have a wonderful day.
Sarah


Note: I can see a PR template was briefly mentioned before[4] when 
discussing adding a pre-commit but I can't mind other mentions so far. 
Sorry if it has already been discussed.


[1]: 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
[2]: 
https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#task-lists
[3]: 
https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-collapsed-sections
[4]: https://groups.google.com/g/django-developers/c/LVWssSldjVs/m/DJcheek3AgAJ

-- 
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/bc0cb58e-5366-4119-9161-c3cc5dd85012n%40googlegroups.com.

Re: Easy Pickings: support robust on_commit handlers

[Revanth GSS]

Hi Josh,

I am also interested to work on this ticket. I am also aware of how can I 
execute this. It would be great if I could contribute as I am eagerly 
waiting to have my first contribution to Django. However, I would also be 
happy to help anyone who is willing to contribute.

Thanks,
Revanth
On Wednesday, April 6, 2022 at 11:08:04 PM UTC+5:30 omanir...@gmail.com 
wrote:

> Hi Josh, all 
>
> I am interested to work on this ticket, this would be my first time 
> contributing. 
> I have read and worked through the article "Writing your first patch for 
> Django".   I should be fine with the getting started part. 
>
> I am looking for someone  reach out to personally to get my thoughts 
> validated/ get help. 
>
> thanks
> On Monday, 4 April, 2022 at 10:20:45 am UTC+5:30 josh.s...@gmail.com 
> wrote:
>
>> I've just created a ticket for supporting robust on_commit handlers that 
>> I think might be a good first ticket for somebody looking to get into 
>> contributing to Django.
>>
>> https://code.djangoproject.com/ticket/33616
>>
>> I'd be more than happy to review any patch and provide guidance if 
>> required. It's been quite a while since I've contributed directly so I may 
>> not be too helpful in the "getting started" phase, but the existing 
>> documentation would be a good place to begin 
>> https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/
>>
>

-- 
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/fde9776c-2d81-4462-91bb-e280a7ba227dn%40googlegroups.com.

MFA (2FA)

[Yonas]

Hello,

The idea to implement MFA (2FA) has been brought up a couple of times over 
the past years. And the community seems interested.

I am willing to implement this feature (HOTP, TOTP, and email). However, a 
QR code generator is required. 

If someone can help with this, it would be awesome. Otherwise, what do you 
think about bringing a third-party QR code generator into core?

If both options are not feasible, displaying the secret key to the user is 
another alternative (not ideal). But the developer has the freedom to 
install a third-party package and show the QR code.

Best,
Yonas

-- 
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/1d65ecc4-01a3-461e-bf72-e576a5860345n%40googlegroups.com.

Re: MFA (2FA)

[Tobias Bengfort]

Hi Yonas,

the best place to start is probably to look at thrid party packages, e.g.:

https://github.com/django-otp/django-otp
https://github.com/jazzband/django-two-factor-auth
https://github.com/mkalioby/django-mfa2
https://gitlab.com/stavros/django-webauthin
https://github.com/xi/django-mfa3 (mine)

I am not convinced that moving this into django is the best approach 
though. There is just so many ways you can do MFA/passwordless. Recovery 
in particular is complex with a lot of different solutions, depending on 
context.


I also noticed that you omitted FIDO2/webauthn from your list of 
protocols. It is the newest of these protocols and requires a very 
different architecture, but I guess that IETF and W3C had reasons to 
choose it.


I do agree that a simple, opinionated solution in django itself could 
push 2FA adaption and therefore general security on the web, which is 
clearly a good thing. But I still think this works better in a third 
party app such as django-mfa3.


best,
tobias


On 07/04/2022 14.42, Yonas wrote:

Hello,

The idea to implement MFA (2FA) has been brought up a couple of times 
over the past years. And the community seems interested.


I am willing to implement this feature (HOTP, TOTP, and email). However, 
a QR code generator is required.


If someone can help with this, it would be awesome. Otherwise, what do 
you think about bringing a third-party QR code generator into core?


If both options are not feasible, displaying the secret key to the user 
is another alternative (not ideal). But the developer has the freedom to 
install a third-party package and show the QR code.


Best,
Yonas

--
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/1d65ecc4-01a3-461e-bf72-e576a5860345n%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/70d203e5-1eed-aa7f-d31c-2466321a283d%40posteo.de.

Re: Ticket #21289 - Login rate limiting

[Tobias Bengfort]

Hi Jacob,

I actually do like that idea! I don't think it is a good default for 
django in general, but I would be interested in a reusable app that 
implements this. Is this already available somehwere?


thanks,
tobias


On 05/04/2022 16.04, Jacob Rief wrote:

How about this proposal?

Someone opens the login page. In addition to the visible 
fields username and password and the hidden field csrftoken we add 
another hidden field. This field contains the earliest 
(server-)timestamp a user might login, and lies in the near future, for 
instance now() + timedelta(seconds=5). That value is cryptographically 
signed 
.


In addition to this, we disable the submit button and add a small 
Javascript function which sets an interval corresponding to the 
mandatory login delay. After that interval expired, the submit button is 
enabled again.


A malicious client who bypasses the disabled button and attempts to 
submit the login for, will receive a HTTP response with an error code > 400.


What are the advantages?

  * Django doesn't have to store any state of users and/or IP addresses
attempting to log in.
  * Django doesn't have to delay itself to throttle requests. This btw.
is a DoS attack vector by blocking server threads.
  * We transfer responsibility for delaying login requests to the client
– who can't bypass them.

--
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/b64d44a3-c7dd-4f9a-bf4f-1b8e9818fb64n%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/25495738-17c0-11e8-22ed-6c17dd3862fd%40posteo.de.

Re: MFA (2FA)

[Yonas]

Hi Tobias,

Thanks for the feedback. 

There are multiple ways to implement MFA, as you mentioned. But the goal 
here is to provide a simple mechanism. It's "not necessary" to cover every 
use case, and I believe that's where third-party packages come in.

Based on a study conducted by Microsoft, a user account is "99.9% less 
likely to be compromised if" the user uses MFA. So, it would be beneficial 
to have this feature in Django.
On Thursday, April 7, 2022 at 9:55:32 PM UTC+3 Tobias Bengfort wrote:

> Hi Yonas,
>
> the best place to start is probably to look at thrid party packages, e.g.:
>
> https://github.com/django-otp/django-otp
> https://github.com/jazzband/django-two-factor-auth
> https://github.com/mkalioby/django-mfa2
> https://gitlab.com/stavros/django-webauthin
> https://github.com/xi/django-mfa3 (mine)
>
> I am not convinced that moving this into django is the best approach 
> though. There is just so many ways you can do MFA/passwordless. Recovery 
> in particular is complex with a lot of different solutions, depending on 
> context.
>
> I also noticed that you omitted FIDO2/webauthn from your list of 
> protocols. It is the newest of these protocols and requires a very 
> different architecture, but I guess that IETF and W3C had reasons to 
> choose it.
>
> I do agree that a simple, opinionated solution in django itself could 
> push 2FA adaption and therefore general security on the web, which is 
> clearly a good thing. But I still think this works better in a third 
> party app such as django-mfa3.
>
> best,
> tobias
>
>
> On 07/04/2022 14.42, Yonas wrote:
> > Hello,
> > 
> > The idea to implement MFA (2FA) has been brought up a couple of times 
> > over the past years. And the community seems interested.
> > 
> > I am willing to implement this feature (HOTP, TOTP, and email). However, 
> > a QR code generator is required.
> > 
> > If someone can help with this, it would be awesome. Otherwise, what do 
> > you think about bringing a third-party QR code generator into core?
> > 
> > If both options are not feasible, displaying the secret key to the user 
> > is another alternative (not ideal). But the developer has the freedom to 
> > install a third-party package and show the QR code.
> > 
> > Best,
> > Yonas
> > 
> > -- 
> > 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/1d65ecc4-01a3-461e-bf72-e576a5860345n%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/django-developers/1d65ecc4-01a3-461e-bf72-e576a5860345n%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/87921818-06cf-4e1e-976f-69d444edbd15n%40googlegroups.com.