Re: 2020 Authentication Initiativ

[Florian Apolloner]

Hi Joe,

On Thursday, April 11, 2019 at 4:56:05 PM UTC+2, Johannes Hoppe wrote:
>
> @Florian, since I had so many PRs pending review, I had to find other ways 
> to cause chaos ;)
>

Hehe probably, the autocomplete stuff is on my todo for the sprints (and 
selenium is mainly waiting for a merge).

I would suggest as a first step to separate the field names from the object 
> methods. Thanks to multi inheritance in Python this should be an easy 
> enough task.
>

Personally I do not think this should be the first thing to do. At least 
for me the most common way to login is still an identifier + a password in 
combination with a second factor. And since u2f/totp/webauth do not really 
need anything from the usermodel aside from a PK for a foreignkey or so, 
this would be a good starting point. I think that, if needed, cleaning up 
the user model would be technically easy but hard from a backwards 
compatibility perspective. Introducing a new authentication flow/pipeline 
while technically hard would probably be relatively easy to add (new 
feature and settings while still supporting the old ones for a while).

I will look into it a bit and propose something as a base for discussion.
>

Yes please, the more written things we have the more we can discuss it and 
have something concrete getting out of it.

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 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/ed051fa5-e65d-45dc-863e-7f81885b5be8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Converting serve static to class base views

[Florian Apolloner]

Hi,

as written on the ticket already you have to present __why__ and __what__ 
your class based view makes easier. As it currently stands I cannot see 
anything which you couldn't also achieve by "inheriting" the function based 
view.

Cheers,
Florian

On Thursday, April 11, 2019 at 11:05:36 PM UTC+2, Thomas Turner wrote:
>
>
> Hi all
>
> I want to make a case for converting the Serve Static to Class Base View 
> it is ticket number 30344 https://code.djangoproject.com/ticket/30344
>
>
> I am the maintainer of a project called Django Tenants ​
> http://github.com/tomturner/django-tenants which allows you to have 
> tenants in Django ie a.mydomain.com and b.mydomain.com. The problem I 
> have is that on the different domains I want to serve different static 
> files. The problem is I cant pick up the domain and set the correct tenant 
> for static files. I believe this could be done easier if the serve static 
> is class based. Making the serve static class base will not affect users of 
> Django and I know a lot of other areas in Django have been converted to 
> class base views such as the admin
>
>
> I believe one could override the entry point could be manual added to a URL
>
>
> re_path(r'^site_media/(?P.*)$', 
> static.ServeStatic.as_view(document_root=media_dir, show_indexes=True))
>
>
> I know server static should only be used for development use only.
>
>
>
>
>
>

-- 
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/2236b26f-51d7-4cad-a986-e6726e7ac192%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Video Calling application using Django

[K Surya Kumar]

Hi,
 I'm planning to build a video chatting web app using django framework 
for my pg project. But i don't have a clear idea how to start with building 
video chatting app (flow) and i came across those terms like WEB RTC like 
that when searching for web video chatting api's.

Can't anyone guide me how to start with it.

thanks in advance,
Surya

-- 
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/ca03b9ee-f45f-4437-9637-eea2ff93fdcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Video Calling application using Django

[Mat Gadd]

This mailing list is for the development of Django itself, not for support 
using Django. Please use the django-users mailing list for that, or IRC #django 
on freenode, or a site like Stack Overflow.

> On 12 Apr 2019, at 06:39, K Surya Kumar  wrote:
> 
> Hi,
>  I'm planning to build a video chatting web app using django framework 
> for my pg project. But i don't have a clear idea how to start with building 
> video chatting app (flow) and i came across those terms like WEB RTC like 
> that when searching for web video chatting api's.
> 
> Can't anyone guide me how to start with it.
> 
> thanks in advance,
> Surya
> 
> -- 
> 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/ca03b9ee-f45f-4437-9637-eea2ff93fdcc%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/4E3292A2-61FF-467B-B632-8F0832F05CA3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2020 Authentication Initiativ

[René Fleschenberg]

Hi

> Also related: UserCreationForm by default allows usernames that differ
> only by case
> https://code.djangoproject.com/ticket/25617

I would like to mention CITextField / CIEmailField here. It solves this
problem nicely, in my experience.

However, it is only available on Postgres, and it requires a database
extension that in turn requires superuser access to the database to be
installed.

Do you think it would be realistically possible to have a CITextField
that uses Postgres citext when available and falls back to Python in
other cases?

-- 
René Fleschenberg

-- 
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/f91b347e-7fc9-f559-c5d4-e2c1124aadfd%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.

Re: 2020 Authentication Initiativ

[Johannes Hoppe]

So I spend a little time fiddling around Django to understand what is possible 
and where there might be room for API improvements.

I went with the hardest possible way, NO password, NO username. Just one time 
passwords send via email or SMS. Similar to Django’s password reset function.

I published my work just now, https://django-mail-auth.rtfd.io. I would 
recommend to have a look at the custom EmailUser that I built. There are a 
couple of functions and fields that need to be overridden. BUT to my surprise 
even the management command “createsuperuser” worked.

Anyhow, I am curious to get a little bit of feedback to further investigate the 
different possibilities and implications this might have for Django’s 
authentication framework.
On 12. Apr 2019, 18:49 +0200, René Fleschenberg , wrote:
> Hi
>
> > Also related: UserCreationForm by default allows usernames that differ
> > only by case
> > https://code.djangoproject.com/ticket/25617
>
> I would like to mention CITextField / CIEmailField here. It solves this
> problem nicely, in my experience.
>
> However, it is only available on Postgres, and it requires a database
> extension that in turn requires superuser access to the database to be
> installed.
>
> Do you think it would be realistically possible to have a CITextField
> that uses Postgres citext when available and falls back to Python in
> other cases?
>
> --
> René Fleschenberg
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/d92P2V0YrbI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/f91b347e-7fc9-f559-c5d4-e2c1124aadfd%40fleschenberg.net.
> 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/ccd774f9-db56-4588-97e4-b44370539013%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Last week we had an average hit ratio of around 63%, including ~10 purges
that dropped the rate down temporarily before the cache rebuilt:
[image: Screenshot 2019-04-11 09.37.57.png]
In terms of bandwidth, we're averaging around 5 GB/day for docs and 10
GB/day for static. Giving static its own domain may actually be saving us a
good bit of bandwidth (previously each subdomain had its own /s/ prefix
from which an identical set of static files was served).

Cheers,


*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com


On Sun, Mar 31, 2019 at 3:08 PM Tobias McNulty 
wrote:

> On Sat, Mar 30, 2019 at 7:32 PM Tom Forbes  wrote:
>
>> I’m a stats nerd, and I think I’m not alone on this list in that respect,
>> would it be possible to share some more numbers after a week of usage? I
>> would be interested in the total bandwidth used/saved, the global
>> distribution of requests and the average requests per second. If I remember
>> correctly fastly has a fantastic live dashboard with all of this info.
>>
>
> For static, I think we'll end up using just under 300 GB a month, or about
> a quarter of the total bandwidth served by this particular server (which
> also handles most other djangoproject.com subdomains). I'll see if I can
> collect some slightly more interesting numbers after a week or two.
>
> I’m not entirely clear on the HTTP/2 issue, does Fastly not terminate
>> these and forward on http 1.1 requests? Could you elaborate a bit?
>>
>
> HTTP/2 supports connection coalescing
> ,
> where the browser (with varying degrees of aggressiveness, depending on the
> manufacturer) may reuse existing connections for different subdomains. In
> our case, Fastly originally provisioned a wildcard SSL cert ('*.
> djangoproject.com'), so *we think* that some versions of Firefox were
> reusing HTTP/2 connections originally established for
> static.djangoproject.com for requests to www.djangoproject.com, *even
> though* there was no overlap in IPs for the two domains. In the browser
> (courtesy of Mariusz) it looked like this:
>
> [image: Screenshot_20190320_113825.png]
> Clicking on the cert icon showed the wildcard cert from Fastly, not our
> Let's Encrypt cert, as well. In other words, it appeared Firefox was
> ignoring DNS for www.djangoproject.com and assumed that it could send
> those requests to static.djangoproject.com instead, simply because the
> server responded with an SSL certificate that matched
> www.djangoproject.com. I.e., it appeared to be *even more aggressive* than
> described under "The Firefox way" in the link above.
>
> I find this explanation entirely dissatisfying (if not altogether
> frightening), so part of me hopes I've got it wrong. :-\
>
> In any case, after requesting that Fastly de-provision the wildcard cert
> and include only the specific domains we needed, the issue went away. There
> is an HTTP status code (421) that can be used to tell the browser it's made
> such an error, so I believe we also could have solved this by setting up a
> catchall service in Fastly to return HTTP 421 for any requests received on
> subdomains we weren't expecting. But avoiding the spurious requests to
> begin with seemed like a better solution, and provisioning certs only for
> the domains we need is cleaner to begin with and seems to have fixed the
> problem.
>
> I was never able to reproduce this in Firefox myself, but I did see
> evidence of it occurring insofar as we *also* started getting a very
> small number of requests to the '*docs*.djangoproject.com' service in
> Fastly after changing the DNS for '*static*.djangoproject.com.' Of
> course, no one would have noticed these because the requests returned
> successfully, but they should not have been going through Fastly (until the
> DNS was changed for 'docs', of course). Mariusz may be able to add
> something about the when/how he saw this; I do think it was fairly
> intermittent. Anyways, I'm pretty sure this would have gone undiagnosed for
> weeks if not months if he had not noticed and alerted us to the issue
> (causing all sorts of frustration and confusion in the meantime), so thank
> you again, Mariusz!
>
> Cheers,
> Tobias
>

-- 
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/CAMGFDKSR32g%2Bib7KSyuYmeajdBDuNuZg%3Di346Ly54MaW1Q1FCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.