DjangoCon Europe coming to Copenhagen: It's participatory!

[benjaoming]

Dear Djangonauts,

The ticket sales for DjangoCon Europe 2019 have opened, and the Call for 
Participation is closing in 3 days (rumor: we might extend it by a few 
days).

In case you've just seen this: Sorry for the late notice!

DjangoCon is a conference by the community and for the community. Allow us 
to make amends for the late notice by suggesting the following ways to 
participate:

   1. Be an attendant! Get your ticket early 
   

 
   and save a bit.
   2. Be a speaker: Respond to the Call for Participation 
   

   3. Get your company engaged in sponsoring 
   
:
 
   Reaching out to the Django community has mutual benefits.

You can read much more on the website about giving talks or the many 
opportunities of sponsorships.

https://2019.djangocon.eu/

Hope to see you here in Copenhagen soon,
Ben (co-organizer of the event)

(and Dawn, Emil, Elvis, Jessica, Mads, Reaz, Sarah, Thomas, Víðir and 
Xavier)

-- 
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/da0c2065-f8e7-4615-a9d4-43e06a98c6ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sprint announcement: Copenhagen, Saturday March 17

[benjaoming]

Hi all!

Here-by announcing that in the days after our first ever Danish Django 
conference (DjangoCPH Day 2018), we'll host a sprint. It's free to attend, 
as long as you sign up on the website.And you are of course encouraged to 
participate in the event on Friday as well *wink wink* :)

Markus Holtermann will be our core guide as well as giving a talk on the 
conference day, and we are super glad that he's taking the time to come 
over and make this happen! Thanks Markus!

For more information, see: https://djangocph.dk/ (exact times of the sprint 
are pending)


Best,
Benjamin

-- 
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/32cdaab7-4a5c-4534-9b24-c9b854fb8106%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

[benjaoming]

As a big fan of GCBVs, this got me out of the chair :) I am -1 for removing 
GCBVs for authentication.

My reasons:

1) Security improvements also happen over time, finding a security hole in 
a component is not a reason to point the finger at the architecture. If you 
entirely remove something, you will have to rebuild it somewhere else, and 
new security holes will emerge. Thinking that users of builtin GCBVs will 
just opt for the FBVs is wrong, we won't, we'll write our own GCBVs or find 
some third-party that has less attentive eyes than the django.contrib.auth

2) In this case, having security checks in `get_context_data()` is far from 
the intentions of that method. If I override it, I would not expect 
security properties of the view to be removed, right? We shouldn't put 
security checks there, simple as that. If we assume the design pattern is 
(G)CBV, then this is a violation of the design principles and should have 
been rejected even before the security issue happened. In a GCBV, we should 
always ask "Is this logic to be expected by someone inheriting from this 
GCBV".

3) People have implemented and deployed GCBV from auth. The consequence of 
removing them because we don't want to deal with their security issues is 
alarming! I inherit from these classes, believing that we will be stronger 
together, because inheriting from a common codebase will have more eyes on 
the security aspects. This will be a bad example or bad signal to set for 
other usages of GCBVs.

4) SomeViewClass.as_view() generates an FBV, I'm sure we can bridge CBVs 
and FBVs if the concern is about having separate codebases as Baptiste 
expressed it.

5) I fully agree with Baptiste: If Django does not supply easily pluggable 
authentication patterns, someone else will (and not just 1 project, many 
will popup, they already have), and the effort will be fragmented, the 
security will be weakened.

6) I write CBVs in my own apps, I know there is a lot of afterthought and 
you often have to move logic between CBVs, mixins, and method decorators. I 
fully understand and sympathize with release notes that have entries about 
design changes and small refactors in GCBVs, that's awesome and you can 
learn from the considerations and decisions in Django's GCBVs.


Thanks :)
Ben


On Monday, November 21, 2016 at 8:11:34 PM UTC+1, Markus Holtermann wrote:
>
> Hi all,
>
> As it turned out [1], due to their complexity, using class-based generic 
> views for security-sensitive functionality can result in unintended 
> behavior. Essentially, the reset token was only checked on GET requests, 
> not on POST. This was due to the check being in `get_context_data()` (which 
> is only called on GET but not POST except for invalid forms) and not higher 
> up the stack. Validation could happen in the SetPasswordForm but doesn't 
> really belong there either. The form is being used by the admin to allow 
> superusers to change other users' password. Also, password resets could 
> probably happen via other ways that want to leverage a form that doesn't 
> require a token. In the end, from my perspective the check for the correct 
> token does belong in the view.
>
> While the reported issue was fixed [2] it raises the question if the added 
> functionality of class-based generic views is worth the danger of shooting 
> ourselves in the foot. I see the benefits of GCBVs. But given that the 
> reported issue stayed unnoticed for 4 months makes me think that those 
> views are not the best for these use cases and easily underpin the security 
> functionality. Hence I suggest to revert the patch (including all 
> additional features they gained) unless they are integrated in the 
> function-based views and add guidelines on how to use class-based generic 
> views for security sensitive feature.
>
> This is the thread to get the discussion about this started.
>
> One thing I want to suggest regardless if the class-based generic views 
> are removed again or not, is to hold off the deprecation of the 
> function-based views. This allows users who feel the same to not use 
> class-based generic views without having deprecation warnings. At least 
> until the next LTS release.
>
> Furthermore, myself and Florian Apolloner, who discovered the issue, are 
> leaning +0 to +1 on the revert of the class-based views.
>
> Cheers,
>
> Markus Holtermann
>
> [1] 
> https://www.djangoproject.com/weblog/2016/nov/21/passwordresetconfirmview-security-advisory/
> [2] https://github.com/django/django/pull/7591
>

-- 
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 

Re: Experimental APIs DEP

[benjaoming]

Hi guys!

As an external user of Django, relying on its stability, I'd like to 
comment In general, I think this is possibly a good improvement.. but 
possibly also a very dangerous one...

On Monday, December 8, 2014 12:38:18 AM UTC+1, Russell Keith-Magee wrote:
>
>
> On Sun, Dec 7, 2014 at 6:35 PM, Shai Berger  > wrote:
>
>> I like the general idea of experimental API, although Carl and Aymeric's 
>> notes
>> are important: If we do this, we need to very picky in its use, or else it
>> just becomes an easy route to avoid committment. In particular, there 
>> should
>> be a hard-and-fast rule that nothing should be made an "experimental API" 
>> if
>> it can just be done outside of core.
>>
>> For the example given -- backend API -- I think that, again, Carl and 
>> Aymeric
>> are right; the examples I have more in mind for this are user-facing ORM
>> features like the expressions, or custom lookups. I think it might be 
>> better
>> to let people play with them more, in a released version, before setting 
>> the
>> APIs in concrete.
>>
>> With that in mind, I would also reconsider adding a silent warning when 
>> the
>> features are used -- because, if they are for general use (as opposed to 
>> the
>> use of, say, 3rd-party backend developers) then there's a significant 
>> use-case
>> where the person who would use the API is not the person who configures 
>> the
>> warnings on the CI.
>>
>
> To my mind, the role of this new status is closer to "provisional", rather 
> than "experimental". It's a recognition of the fact that no matter how many 
> times we ask for pre-release testing, the first *real* test of any API is 
> when it sees real-world use. 
>


What I would fear is not so much that experimentals/provisionals end up in 
other parts of Django itself: The Django team is well-disciplined and will 
understand its own release protocol :)

I'm more worried that the application ecology starts suffering from 
symptoms of an experimental attitude in the Django project...

This DEP would definitely have to be understood by the outside 
app-developer: For the stability of third-party apps, app maintainers 
should consider to put "don't use experimental APIs" in their contribution 
guidelines and make sure to go through the painful process of rejecting 
well-intended PRs relying on experimental components. Especially if it's 
decided not to raise Warnings when experimental modules are imported.

For the projects and applications that do use experimentals, it would be 
nice to have a guarantee of a smooth API transition when the next Django 
ships. DEP states that APIs can change, but that it *shouldn't* do so. If 
stated that the API should not change, that causes for a much more 
significant guarantee, and sets the bar reasonably high for new 
experimental components.

The amount of deprecations in Django in general is very high, and 
currently, supporting both South and db.migrations is quite hard. So adding 
more complexity to multi-version Django support does not sound very 
attractive to me and should be avoided at all costs.

Some suggestions for the "experimental" definition / ruleset:

   - API has been thoroughly agreed and is not subject to change.
   - Only stability and performance is a questionable part that makes a 
   feature experimental.
   - Internal parts of an experimental component are expected to change 
   more than usual
   - Something does not get pulled out without a deprecation warning, even 
   though it's experimental

If experimental components will be allowed to change their APIs, I would 
definitely suggest a Warning to be raised so they're kept out of the app 
ecology.
The relevant part of the DEP reads:

Instead, an Experimental designation will allow APIs to be included in 
> Django and released without being beholden to the full deprecation cycle.
>

If you allow that to happen, then in essence, anything can be released and 
removed again. But there should be a clear intention when something is 
released, that it will be made permanent, right?

DEP also states:

Effort will be taken to communicate to users that the APIs in question are 
> not stable to avoid inadvertent use.
>

I don't think that's possible. If the feature is attractive, it will be 
used.

RKM wrote:

due to fears over whether the public-facing API is suitable for use. 
>

This could be rephrased: Because some components do not get the exposure 
necessary for thorough testing through the availability and use of the beta 
releases, we need experimental components in the final releases.

The goal is to get a broader test audience for *more rapid* releases and to 
have *faster* maturing of new features. Just be careful that this stuff 
doesn't end up where it's not supposed to, that's my main worry.

Other than that, it's really easy to release django applications, and 
features not agreed to enter the django mainline have always been referred 
to release as an external 

Re: Forced password reset in django-admin

[benjaoming]

Hello again!

> What you have suggested here **is** an invasive change, because it
> requires changes to existing code paths.

I think the way to measure "invasive" is by means of backwards
compatibility. We do not change required arguments, return value or
model fields... The view normally responds with an
HttpResponseRedirect object, and that's also the case here.

> A setting is not a good way to
> make something configurable here. A keyword argument here *would* be an
> acceptable solution.

You're right. Keywords argument is a good idea!

> However, I don't think it would be that useful, because if it was off by
> default, and controlled by a keyword argument, then the admin login view
> wouldn't use it. I think this needs more thought.

True! Actually this speaks against the use of a keyword argument as
sole option.

Keyword option: Local per-view behavior
Setting variable: Project-wide behavior used when there is no kwarg
present

> Again, I should mention that features like this get implemented by the
> community. If you need it, the way to do it is to build it, and then
> persuade us to use it - not to try to persuade *us* to build it :-)

I'm actually trying to persuade myself to build it in case there's
enough support+discussion for it.

> BTW - this doesn't actually force the password reset - it logs them in
> and then asks them to change their password. If they don't they are
> still logged in.

Yup, that needs more thought!

all the best,
Benjamin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Forced password reset in django-admin

[benjaoming]

> > As a maintainer of many Django sites, I would often like to see a very
> > small feature implemented, that could make life a lot easier for me:
> > To force my users to set their own password.
>
> First, to me, this is not obviously a 'very small feature'.
>
> Second, is there any reason it has to be in core? Ideally it could be
> implemented in 3rd party library. At that point it would be useful to
> you, and we could assess whether it is general enough to be in core.

I'm sorry if "core" was the wrong use... "contrib.auth" is what I
meant.

How so do you find it an invasive change? I think it could be solved
easily, even without being backwards incompatible.

This type of login behavior is standard in Google Apps, which is why I
find it not to be something I've made up just for my own needs!

Here's a way to do it:

When a user has never been logged in, User.last_login is the same as
User.date_joined -- so we actually do not need a new model field! We
can rely on this behavior as a sort of "intended" logical derivation
from the fact that they are equal :) Furthermore, I would propose of
course to make the behavior configurable and turned off by default.

The whole conditional redirect could easily be put in
django.contrib.auth.views - all we need to do is put 4 lines of code
on each side of auth_login(request, user) in the login(...) view -
like 'dis:

def login(request, template_name='registration/login.html',
  redirect_field_name=REDIRECT_FIELD_NAME,
  authentication_form=AuthenticationForm,
  current_app=None, extra_context=None):
"""
Displays the login form and handles the login action.
"""

(...)

if form.is_valid():

(...)

# The form is valid... and now I would propose inserting
something like:
user = form.get_user()
force_password_reset = False
if settings.AUTH_FORCE_USER_PASSWORD_RESET and
user.last_login == user.date_joined:
force_password_reset = True

# Okay, security checks complete. Log the user in.
auth_login(request, user)

if force_password_reset:
# Manipulate last_login so that the user will be
consistently redirected on each login, until the password is reset.
user.last_login = user.date_joined
user.save()
redirect_to =
reverse('django.contrib.auth.views.password_reset'))

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Forced password reset in django-admin

[benjaoming]

Dear all,

As a maintainer of many Django sites, I would often like to see a very
small feature implemented, that could make life a lot easier for me:
To force my users to set their own password.

I know this could lead to a long debate about password strength, SSL,
password reminders, secret answers etc... but for me, the most urgent
problem is that people have to be reminded manually about their
passwords, and I have to reset them pretty often (or find copies of
emails that i've sent).

I always tell people to click the Change password link. But they
don't!

So the problem seems to be that ordinary users do not change their
password, forget it, delete the original email (or are too lazy to
find it), and then some poor administrator has to make another one.

Forcing people to reset their password upon login is a common feature
in Google Apps btw.

What are people's opinions? Should this be a core feature?

Django-love,
Benjamin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.