Django include default user registration, forgot password, OTP feature by default with Django libraries

[parocks]

I have been working with Django for small clients.
One of the feature I would really love to have is 
1. Default User Registration feature (without having to fiddle with things 
like the admin portal)
2. Forgot password feature 
3. OTP for all user registrations by default

Those three are the missing ones from my opinion.
If thats included I would say Django will beat most of the frameworks in 
the market.

Looking forward for easy enablement of those 3 features natively into 
Django.
Please consider documenting it in the api atleast.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/02b42c58-edb5-4bab-b745-1dc985e264d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django 2.1 default of samesite=Lax for Session and CSRF cookies cause issues on Safari 12

[Flávio Junior]

Hi folks,
after upgrading to Django 2.1, we noticed many occurrences of 403 CSRF 
errors for Safari 12 users.
After days debugging the problem, we've pinpointed the issue to the Webkit 
Bug 188165: https://bugs.webkit.org/show_bug.cgi?id=188165

In simple terms, Safari 12 implementation of samesite=Lax cookies is wrong.
It causes issues in many common request flows, like the OpenIdConnect flow 
for ASP.NET Core 2.1.

For Django, the issue might be considered even worse. If the user comes 
from a cross-site redirection (like a tracker link from an email provider), 
Safari doesn't send samesite=lax cookies on the request. This causes 
multiple issues. We've been able to identify those three, but maybe there 
are more:
- User will not be logged in if SESSION_COOKIE_SAMESITE = 'Lax'. That 
behavior is only expected if 'Strict', AFAIK.
- User will not be able to make AJAX POST requests if CSRF_COOKIE_SAMESITE 
= 'Lax', because JS code won't be able to read the CSRF cookie.
- POSTs on other open tabs/windows will fail if CSRF_COOKIE_SAMESITE = 
'Lax', because Safari triggered a CSRF cookie update after the first 
request without cookies.

Those issues do not happen on Chrome, nor Firefox.
Full Django project example of the problem above is available here: 
​https://github.com/vintasoftware/safari-samesite-cookie-issue

Since Safari 12 is the current stable version and it's widely deployed on 
iOS devices, I believe the Django default for CSRF_COOKIE_SAMESITE and 
SESSION_COOKIE_SAMESITE should be None, not Lax.

Upgrading to Django 2.1 caused this issue to us and frustrated many users. 
I think a more conservative default is necessary here to avoid breaking 
common use cases like visiting a web app page logged in after receiving a 
transactional or scheduled email.
If you do not wish to change the defaults, IMHO at least a warning should 
be placed on the documentation. For comparison, Microsoft issued a security 
advisory describing the bug on 
ASP.NET: https://github.com/aspnet/Announcements/issues/318
Please let me know your thoughts, I can help with a PR if needed.

Related Django ticket: https://code.djangoproject.com/ticket/30250

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c0911f7b-f4e9-466b-bb72-ede732a5a41a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django include default user registration, forgot password, OTP feature by default with Django libraries

[Jani Tiainen]

Hi.

ke 13. maalisk. 2019 klo 18.19 parocks 
kirjoitti:

> I have been working with Django for small clients.
> One of the feature I would really love to have is
> 1. Default User Registration feature (without having to fiddle with things
> like the admin portal)
>

Registration is not a simple thing. There are quite many ways to make
registration happen which is the reason that Django doesn't have any
default implementation for it. You can find several goid 3rd party packages
that handles different kind of registrations.

Also you may find that some would like to handle registration by Facebook,
Google account, LDAP and who knows what else there exists.

2. Forgot password feature
>

Django has it already. It's called reset password in contrib.auth

3. OTP for all user registrations by default
>

OTP like by TOTP, SMS messages, email or USB dongles or some other means?

And don't you want to have it in login rather than just in registration?

Like you see it's not trivial.


> Those three are the missing ones from my opinion.
> If thats included I would say Django will beat most of the frameworks in
> the market.
>
> Looking forward for easy enablement of those 3 features natively into
> Django.
> Please consider documenting it in the api atleast.
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/02b42c58-edb5-4bab-b745-1dc985e264d1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHn91od53ZUAxBgziRch5SZfqbRrf4fDEgt9cifA0Y5h2SiAwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

GSOC 19 PROPOSAL IDEA

[Chinmay Relkar]

Hi,
   My name is Chinmay Relkar. I'm a final year undergrad from India.
This is about my GSOC proposal idea.

   While playing with django, I've always come across the absence of
bidirectional ManyToMany feature ticketed at
*code.djangoproject.com/ticket/897
*.
I would like to work on this feature as a part of the GSOC program.

   To me this feature feels a bit small for a 12 week program. So
here's something I would like to add on:

While adding a Model item in the admin interface with a ManyToMany
field, we get a MultiSelectWindow to choose multiple items of the related
model. This UI isn't very intuitive.

Taking inspiration from the Chips Component defined in Material Design
Guidelines at *https://material.io/design/components/chips.html
* I would like to
implement FilterChip for the same multi select window. The example of which
is attached below.

This is not a final proposal. I hope I'm not too late to share this here.

I'm eagerly waiting for a response of feedback and suggestions.

About my experience with Django, I've been working with it for past 2
years. Completed a total of 3 projects, one of which is live at *acsinet.net
* with a heavily customised admin panel.

Talking about my level of expertise, I'm not a master to be true. But I can
customise any component of Django according to the stated requirements.
This is a very rough sketch of the proposal. Any suggestions, remarks or
comments will be of great help.

Hoping to get a feedback soon.

Regards,
Chinmay Relkar

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMz5Zox-QaqDMLUuKrJOvPZOqtJFQ6EiWYMtMYFtC%3DXEW9y4-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for unittest -k option

[Luke Plant]

  
  
I use `--keepdb` a lot, I never knew there was a shorthand and
  even know I do know wouldn't use it. For things like this I
  usually find it easy to remember the long option. So I'm +1 on
  changing it too, without a new shorthand for `--keepdb`. In the
  keyword usage `-k` must be followed by a keyword, so for people
  who did use it the shorthand, the old usage will break loudly
  which is good.

Luke


On 11/03/2019 15:13, François Freitag
  wrote:


  Hi Django Devs,

https://code.djangoproject.com/ticket/30245 suggests supporting Python
unittest `-k` option, to selectively run tests matching a keyword.

Currently, `-k` is the shorthand for `--keepdb` in Django.
A `--filter` flag was suggested to preserve backward compatibility.
Carlton suggested removing the `-k` option from `--keepdb` and reusing
it for unittest `-k`. That would follow unittest more closely, reduce
user confusion and ease maintenance.

What do you think is best? Do you see other options?

If re-taking the `-k` option for unittest `-k`, should a new shorthand
be introduced for `--keepdb`?

Thanks for your time,
François



  




-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ffdefe87-33f9-05c6-ee61-30087deee517%40cantab.net.
For more options, visit https://groups.google.com/d/optout.

Re: Development story for CBV FormViews using GET

[Luke Plant]

  
  
Hi Kyle,
My take would be this: What does the code look like if you don't
  use FormView but just write a function view? How does that compare
  to using a CBV? This may be the simpler method you are missing -
  if you are finding you are fighting with inherited functionality,
  just don't inherit it.
Luke


On 09/03/2019 03:55, Kye Russell wrote:


  
  

  
Hi,


Sometimes it is appropriate to for a HTML form to use
  the GET method for submission (usually search / filter
  forms).


My impression has always been that in order to build a
  FormView-based view that acts on GET data, you have to
  override a few methods on your class (which involves
  understanding how FormView works). Even as someone with a
  fairly good understanding of these classes, I sometimes
  have to reference a previously-written example to make
  sure I've got it right.


I am aware of the existence of django-filter[0] which
  takes care of this for you, however at times I find it
  hard to justify adding it to a project just to deal with
  this.



I have the following questions:


* Is my understanding of the current process correct,
  or is there an easier way that I've missed?
* Is this documented anywhere? I looked at the Django
  'working with forms' documentation[1], and whilst it
  discusses the different scenarios in which you'd use GET
  vs POST, it does not seem to discuss implementations in a
  CBV context.

* Is there enough of a generic use-case where FormView
  / FormMixin / ProcessFormView could be altered to support
  this? Or are there subtleties / nuances in each
  implementation that make a generic solution hard to
  develop?


Sorry if this is the wrong avenue to discuss this. I am
  approaching it from the position of wanting to alter
  Django to better support this use case, but I'm aware that
  I may have just missed a Blessed method in the docs.


Kye



[0]: https://github.com/carltongibson/django-filter

[1]: https://docs.djangoproject.com/en/2.1/topics/forms/





  

  
  -- 
  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 post to this group, send email to django-developers@googlegroups.com.
  Visit this group at https://groups.google.com/group/django-developers.
  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CANK-ykkMtxezA9cHN8jQ_czLn6OYtdDn6JYbjNgASyyqHH-aAw%40mail.gmail.com.
  For more options, visit https://groups.google.com/d/optout.

  




-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/668e083b-d3c1-8a5b-989e-03a0a85d895a%40cantab.net.
For more options, visit https://groups.google.com/d/optout.