Re: ConnectionResetError in test_closes_connection_without_content_length

[Zhiqiang Liu]

Hi Chris, 

I did installed sqlite through brew install sqlite, the error still happens.

On Friday, September 22, 2017 at 7:52:53 AM UTC-4, Chris Foresman wrote:
>
> The problem is the version of SQLite included in recent versions of macOS. 
> The easiest fix we saw was installing Homebrew and then doing a `brew 
> install sqlite`. 

-- 
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/18828bdd-e11d-41c6-91c9-345c3d342e0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Zhiqiang Liu]

Luke,

thanks for the long explanation. I see your points here. I actually saw the 
make token function and was thinking about it what is the best way to do 
with that. I think most people here feel there's need to at least allow 
some flexibility for the time out since there will be cases under a day is 
needed.
I will keep this discussion for a couple of more days to see if we can get 
consensus and how we should implemented if needed.

Zach

On Friday, September 22, 2017 at 3:04:01 PM UTC-4, Luke Plant wrote:
>
> I would be +1 to what Adam wrote from me i.e. just allow the value to 
> accept floats.
>
> However, I don't think it will work due to the way that we round the 
> precision of timestamps to days 
> .
>  
> This was done partly to reduce the number of characters needed to express 
> the timestamp, to keep URLs as short as possible. We would  have to change 
> the mechanism to store more precision into the timestamp. This would result 
> in an upgrade 'bump' for users (i.e. links generated before the upgrade 
> would become invalid after upgrade).
>
> However, I really question whether we need any change here, and whether it 
> would be a good idea.
>
> Having a short expiration time (less than 1 hour) could cause major 
> problems for some people - plenty of systems introduce 5 or 10 minute 
> delays in mail delivery, and with some people's internet connection it can 
> take several minutes to open a web page. This also means that some people 
> end up finishing the process of whatever they were doing the next day (I 
> know I've done this several times on various sites), so a timeout of at 
> least 1 or 2 days is a good default. If you want to come back after the 
> weekend and carry on, 3 days makes more sense as a minimum.
>
> In terms of security, I don't think there is really any need for anyone to 
> reduce below the default at all (see below). So I'm very unconvinced about 
> the need for changing to PASSWORD_RESET_TIMEOUT - it is just unnecessary 
> upgrade work for some existing projects (this is the biggest consideration 
> for me), and it could encourage people to set the value to something low 
> that would decrease usability.
>
> *Security:*
>
> The security of the password reset feature is almost entirely independent 
> of the value of the timeout setting. There are 3 attack vectors I can see:
>
> 1) Someone's email account is compromised, and they then do a password 
> reset on a Django site.
>
> We simply can't protect against this AFAICS.
>
> 2) Someone's email account is compromised, and they find/use a password 
> reset email in the person's inbox.
>
> This is the only scenario for which having a shorter timeout makes a 
> difference. It is somewhat unlikely, because in 99% of cases the attacker 
> would be able to generate a password reset email themselves after 
> compromising the account. For this narrow case where the attacker is 
> unwilling/unable to trigger/receive a new password reset email, it is worth 
> having some protection against them being able to use old tokens, but 3 
> days seems plenty short enough for this situation, especially given the 
> fact that a *used* password reset token immediately becomes invalid due to 
> the way we hash on internal state of the user record.
>
> 3) A brute force attack.
>
> To do this, the attacker has to:
>
> 1. Supply a user ID (let's assume this is easy)
>
> 2. ***Choose*** a timestamp (very easy, just choose the current time)
>
> 3. Create a 20 character hexadecimal hmac that matches both the timestamp 
> and the internal state of the user (see 
> https://github.com/django/django/blob/master/django/contrib/auth/tokens.py 
> ).
>
> Since the attacker can choose the timestamp, the probability of guessing 
> correctly depends **only** on:
>
> 1. The number of bits in the hash (20*4 = 80)
>
> 2. The number of attempts (or, the number of requests per second possible 
> and the time available)
>
> It does **not** depend on the value of the reset timeout **at all**.
>
> If we assume they can make 100 req/s, and they try continuously for 10 
> years, they've got a chance of around 1 in 10^13.
>
> In other words, I reject the premise of the ticket, which is that to 
> improve security some people need to reduce the timeout. It makes virtually 
> no difference to the security of this feature, and in fact you would be 
> protected against almost all realistic attacks if there was no timeout. I 
> imagine that the requirement of "meeting security requirements" mentioned 
> on the ticket is due to people who think this works like a short, 6 digit 
> OTP, for which 3 days would be far too long ( see 
> https://sakurity.com/blog/2015/07/18/2fa.html ). We could put a note in 
> the docs about this, I don't know how to do that in a succinct way apart 
> from to link to a copy of this email or something.
>
> However, if we really do 'need' this change, we 

Re: New Permissions Scheme

[Jamesie Pic]

Have you tried of django-guardian ? What do you think about it ?

TBH I never actually used it (I've been doing Django for 9 years and have
never used a permission table), but I think it does what you want.

>From my experience, permissions are thought of something that can be
calculated on the fly, and that's always been the shortest path. The only
thing is, that you *should* then setup your base queryset per-model
per-user OOAO, and then setup permissions per view.

Also, I don't understand how to make DRY code with the permission system:
check a permission to display or not a link in the template, and also
duplicate this check in the view's dispatch or something.

Nowadays, I prefer to set View.allow to a function I re-use, and call it in
dispatch exactly like jinja templates and have a queryset generator that
takes a user argument that all views in a given url router will use by
default: List, Delete, Update, and so on, rather than maintaining
boilerplate code to maintain a database table when something else changes
in the database.

While I can understand how you could need django-guardian in some projects,
I can understand why you want security as a feature in any project ;)

Keep up the great research !
<3

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

Re: New Permissions Scheme

[Ramez Ashraf]

>
>
> After some some thoughts, i figured out that one route to change how 
permissions work in Django can be done by changing AUTHENTICATION_BACKENDS 
to a Custom ModelBackend Subclass that query for Permissions in a different 
way or from a different model / Table; And this solution can be implemented 
by each developer in their project if they dislike how the current 
permission work or it is simply not enough for them.

So maybe we can be satisfied with the current Permission implementation for 
some more time.

Hopefully this idea -customizing permissions by changing the ModelBackend 
Authentication , leaving the current Permission as it is-  might come in 
handy if anyone is not satisfied with the Django Permissions . 
It can also be stated *more clearly* in the docs.

Greetings to you all.





-- 
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/d69c8163-b57e-4771-b7c0-d66ffbe7faa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Luke Plant]

I would be +1 to what Adam wrote from me i.e. just allow the value to 
accept floats.


However, I don't think it will work due to the way that we round the 
precision of timestamps to days 
. 
This was done partly to reduce the number of characters needed to 
express the timestamp, to keep URLs as short as possible. We would  have 
to change the mechanism to store more precision into the timestamp. This 
would result in an upgrade 'bump' for users (i.e. links generated before 
the upgrade would become invalid after upgrade).


However, I really question whether we need any change here, and whether 
it would be a good idea.


Having a short expiration time (less than 1 hour) could cause major 
problems for some people - plenty of systems introduce 5 or 10 minute 
delays in mail delivery, and with some people's internet connection it 
can take several minutes to open a web page. This also means that some 
people end up finishing the process of whatever they were doing the next 
day (I know I've done this several times on various sites), so a timeout 
of at least 1 or 2 days is a good default. If you want to come back 
after the weekend and carry on, 3 days makes more sense as a minimum.


In terms of security, I don't think there is really any need for anyone 
to reduce below the default at all (see below). So I'm very unconvinced 
about the need for changing to PASSWORD_RESET_TIMEOUT - it is just 
unnecessary upgrade work for some existing projects (this is the biggest 
consideration for me), and it could encourage people to set the value to 
something low that would decrease usability.


*Security:*

The security of the password reset feature is almost entirely 
independent of the value of the timeout setting. There are 3 attack 
vectors I can see:


1) Someone's email account is compromised, and they then do a password 
reset on a Django site.


We simply can't protect against this AFAICS.

2) Someone's email account is compromised, and they find/use a password 
reset email in the person's inbox.


This is the only scenario for which having a shorter timeout makes a 
difference. It is somewhat unlikely, because in 99% of cases the 
attacker would be able to generate a password reset email themselves 
after compromising the account. For this narrow case where the attacker 
is unwilling/unable to trigger/receive a new password reset email, it is 
worth having some protection against them being able to use old tokens, 
but 3 days seems plenty short enough for this situation, especially 
given the fact that a *used* password reset token immediately becomes 
invalid due to the way we hash on internal state of the user record.


3) A brute force attack.

To do this, the attacker has to:

1. Supply a user ID (let's assume this is easy)

2. ***Choose*** a timestamp (very easy, just choose the current time)

3. Create a 20 character hexadecimal hmac that matches both the 
timestamp and the internal state of the user (see 
https://github.com/django/django/blob/master/django/contrib/auth/tokens.py 
).


Since the attacker can choose the timestamp, the probability of guessing 
correctly depends **only** on:


1. The number of bits in the hash (20*4 = 80)

2. The number of attempts (or, the number of requests per second 
possible and the time available)


It does **not** depend on the value of the reset timeout **at all**.

If we assume they can make 100 req/s, and they try continuously for 10 
years, they've got a chance of around 1 in 10^13.


In other words, I reject the premise of the ticket, which is that to 
improve security some people need to reduce the timeout. It makes 
virtually no difference to the security of this feature, and in fact you 
would be protected against almost all realistic attacks if there was no 
timeout. I imagine that the requirement of "meeting security 
requirements" mentioned on the ticket is due to people who think this 
works like a short, 6 digit OTP, for which 3 days would be far too long 
( see https://sakurity.com/blog/2015/07/18/2fa.html ). We could put a 
note in the docs about this, I don't know how to do that in a succinct 
way apart from to link to a copy of this email or something.


However, if we really do 'need' this change, we should at least keep the 
default to what it is now, and put a notice in the docs saying that 
reducing it hurts usability and makes no practical difference to 
security. Since we would be causing an upgrade bump and breaking 
existing links, we may as well also switch to TimestampSigner (the 
password reset code was originally written before that existed), which 
would also mean changing urlconfs I imagine. This would also require a 
significant section in the upgrade notes. (In my book, this is a further 
argument against doing this change at all).



Regards,

Luke
On 21/09/17 12:25, Adam Johnson wrote:
Why not just keep PASSWORD_RESET_TIMEOUT_DAYSand allow 

Django 2.0 alpha 1 released

[Tim Graham]

We've made the first release on the way to Django's next major
release, Django 2.0! With just a little over two months until the
final release (scheduled for December 1), we'll need timely testing
from the community to ensure an on time, stable release. Check out the
blog post:

https://www.djangoproject.com/weblog/2017/sep/22/django-20-alpha-1-released/

-- 
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/CAD-rxRBszJkTg87Ss0oPE0%3DueLOk6p3cSLDteTErUjDAX9QF6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

Finally found it out. There's a browser extension called django version 
switcher hidding in my browser, which is carried over to my new laptop when 
I set it up. The extension will intercept your request to django docs site 
and redirect you to a version it remembered. 

It must be long ago because I didn't remember there is such a thing. 

Thanks for all the help:)

On Friday, September 22, 2017 at 1:30:30 PM UTC-4, Zhiqiang Liu wrote:
>
> Ah it used to happen to all my browsers, now with the new laptop it only 
> happens to Chrome, so it is browser related I think.
>
> On Friday, September 22, 2017 at 1:27:08 PM UTC-4, Zhiqiang Liu wrote:
>>
>> Here it is 
>> HTTP/1.1 302 Found
>> Server: nginx
>> Date: Fri, 22 Sep 2017 17:26:03 GMT
>> Content-Type: text/html; charset=utf-8
>> Content-Length: 0
>> Connection: keep-alive
>> x-content-type-options: nosniff
>> Content-Language: en
>> Location: /en/1.11/
>> x-xss-protection: 1; mode=block
>> X-Frame-Options: SAMEORIGIN
>> Vary: Accept-Language, Cookie
>> Access-Control-Allow-Origin: https://code.djangoproject.com
>> Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
>> Public-Key-Pins-Report-Only: 
>> pin-sha256="og15UrKd7sLz7rIaFIsLD/n3qgqRrXmSQ37/d/8sqi8="; 
>> pin-sha256="deadbeefcafedeadbeefcafedeadbeefcafe111="; max-age=300; 
>> includeSubDomains; report-uri="
>> https://djangoproject.report-uri.io/r/default/hpkp/reportOnly;
>>
>>
>>
>>
>> On Friday, September 22, 2017 at 10:38:13 AM UTC-4, Florian Apolloner 
>> wrote:
>>>
>>> Please provide the output without the grep -- I'd like to see all 
>>> headers. We are sending a 302 redirect to /en/1.11/ for sure ;)
>>>
>>> On Friday, September 22, 2017 at 4:22:03 PM UTC+2, Jamesie Pic wrote:

 Amazing, what's the output when you try `curl -I 
 https://docs.djangoproject.com/en/stable/ | grep Location` ?

 If none, try without the `| grep Location`.

>>>
>>>

-- 
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/c67d40f8-c1c9-46a7-a0c6-cd0f21ef31e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CONTRIBUTION TO DJANGO

[Asif Saifuddin]

Hi Heba khan,

you could give a look on this old PR of mine to have some idea about what 
was suggested to you.

https://github.com/encode/django-rest-framework/pull/4824 

This type of patch to some popular django 3rd party packages would be 
easier for you to get started to open source contrib.

Hope that would help.

Thanks,

./auvipy

twitter.com/auvipy

On Friday, September 22, 2017 at 8:09:30 PM UTC+6, Heba Khan wrote:
>
> Hi Tom! 
>  
> Thank you so much for taking time out and answering my queries. However, 
> I'm still unclear about how to move ahead with all the guidelines suggested 
> by you. I would be extremely grateful if you could guide me a bit more with 
> respect to all your suggestions.
>
> On Friday, 22 September 2017 14:51:46 UTC+5:30, Tom Forbes wrote:
>>
>> Hey Heba,
>> For a few popular packages on Github it could be as simple as making a 
>> merge request and changing their tox.ini or travis.yml file. Once the 
>> django 2.0 alpha is published on PyPi (sometime very soon) you could make a 
>> merge request to run the projects tests with the alpha, and inspect the CI 
>> output for any failures, then fix those. Alternatively, clone each project 
>> and run the tests locally (but this can get tiring for lots of individual 
>> different projects).
>>
>> For example, django-reversion has a tox.ini here: 
>> https://github.com/etianen/django-reversion/blob/master/tox.ini - If you 
>> make a merge request to that project adding Django 2.0 alpha to the `deps` 
>> section (line ~16) and the `test` section (line 4) it will run the tests on 
>> Travis CI and report any failures. You could post on the django-users 
>> mailing list for some ideas of what packages to make changes for (and for 
>> more help with specific things like tox/travis), but I would recommend: 
>> django-reversion, django-mptt, silk and django-debug-toolbar:
>>
>> https://github.com/etianen/django-reversion/blob/master/tox.ini
>> https://github.com/django-mptt/django-mptt/blob/master/tox.ini
>> https://github.com/jazzband/silk/blob/master/.travis.yml
>> https://github.com/jazzband/django-debug-toolbar/blob/master/tox.ini
>>
>> An initial merge request testing on Django 2.0 alpha is the first step, 
>> then fixing any issues that are discovered is the next (and harder) one.
>>
>> On Thu, Sep 21, 2017 at 6:55 PM, Heba Khan  wrote:
>>
>>> Can you suggest a way of how to test Django projects ad third party 
>>> packages please?
>>>
>>> On Thursday, 21 September 2017 21:00:36 UTC+5:30, Adam Johnson wrote:

 There's a whole documentation page on this: 
 https://docs.djangoproject.com/en/dev/internals/contributing/

 There aren't many easy pickings tickets, plus most of the effort right 
 now is being put into features for the 2.0 feature freeze. I'd suggest the 
 biggest contribution you can make right now is testing Django projects or 
 third party packages with 2.0 and finding bugs or helping them become 
 compatible.

 On 21 September 2017 at 15:17, Heba Khan  wrote:

> Hello! 
>
> I'm an undergrad student of B.Tech. in Computer Science and we've been 
> assigned a project to contribute in an open source project. My team 
> members 
> and I decided to pick Django since it is one of the most well known and 
> widely used open source projects. We need help in deciding what 
> contributions to make to the repository and how to go about it. Please 
> keep 
> the following in mind:
>
> 1. We're students with Intermediate coding skills and intermediate 
> knowledge of Python along with a good hold on HTML, CSS, JavaScript and 
> JQuery.
> 2. We need some easy contribution ideas which can be executed in a 
> short span of time. 
> 3. We will be needing guidance and future help from the community as 
> well. 
>
> Thank you in advance. 
>
> -- 
> 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 post to this group, send email to django-d...@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/236511d3-54de-441a-a423-57cc01143be0%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



 -- 
 Adam

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe 

Re: Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

Ah it used to happen to all my browsers, now with the new laptop it only 
happens to Chrome, so it is browser related I think.

On Friday, September 22, 2017 at 1:27:08 PM UTC-4, Zhiqiang Liu wrote:
>
> Here it is 
> HTTP/1.1 302 Found
> Server: nginx
> Date: Fri, 22 Sep 2017 17:26:03 GMT
> Content-Type: text/html; charset=utf-8
> Content-Length: 0
> Connection: keep-alive
> x-content-type-options: nosniff
> Content-Language: en
> Location: /en/1.11/
> x-xss-protection: 1; mode=block
> X-Frame-Options: SAMEORIGIN
> Vary: Accept-Language, Cookie
> Access-Control-Allow-Origin: https://code.djangoproject.com
> Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
> Public-Key-Pins-Report-Only: 
> pin-sha256="og15UrKd7sLz7rIaFIsLD/n3qgqRrXmSQ37/d/8sqi8="; 
> pin-sha256="deadbeefcafedeadbeefcafedeadbeefcafe111="; max-age=300; 
> includeSubDomains; report-uri="
> https://djangoproject.report-uri.io/r/default/hpkp/reportOnly;
>
>
>
>
> On Friday, September 22, 2017 at 10:38:13 AM UTC-4, Florian Apolloner 
> wrote:
>>
>> Please provide the output without the grep -- I'd like to see all 
>> headers. We are sending a 302 redirect to /en/1.11/ for sure ;)
>>
>> On Friday, September 22, 2017 at 4:22:03 PM UTC+2, Jamesie Pic wrote:
>>>
>>> Amazing, what's the output when you try `curl -I 
>>> https://docs.djangoproject.com/en/stable/ | grep Location` ?
>>>
>>> If none, try without the `| grep Location`.
>>>
>>
>>

-- 
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/e8695ce9-408b-4143-b33d-a717693571d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

Here it is 
HTTP/1.1 302 Found
Server: nginx
Date: Fri, 22 Sep 2017 17:26:03 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
x-content-type-options: nosniff
Content-Language: en
Location: /en/1.11/
x-xss-protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Vary: Accept-Language, Cookie
Access-Control-Allow-Origin: https://code.djangoproject.com
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Public-Key-Pins-Report-Only: 
pin-sha256="og15UrKd7sLz7rIaFIsLD/n3qgqRrXmSQ37/d/8sqi8="; 
pin-sha256="deadbeefcafedeadbeefcafedeadbeefcafe111="; max-age=300; 
includeSubDomains; 
report-uri="https://djangoproject.report-uri.io/r/default/hpkp/reportOnly;




On Friday, September 22, 2017 at 10:38:13 AM UTC-4, Florian Apolloner wrote:
>
> Please provide the output without the grep -- I'd like to see all headers. 
> We are sending a 302 redirect to /en/1.11/ for sure ;)
>
> On Friday, September 22, 2017 at 4:22:03 PM UTC+2, Jamesie Pic wrote:
>>
>> Amazing, what's the output when you try `curl -I 
>> https://docs.djangoproject.com/en/stable/ | grep Location` ?
>>
>> If none, try without the `| grep Location`.
>>
>
>

-- 
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/a68d75a9-8c75-429f-a16e-bdbfb609d1e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django Document site always redirect to an earlier version

[Jamesie Pic]

Amazing, what's the output when you try `curl -I
https://docs.djangoproject.com/en/stable/ | grep Location` ?

If none, try without the `| grep Location`.

-- 
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/CAC6Op19udqGVitzwK%2BURw7cYo-h4oayLcpWHUTDsey3yGbz7pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: CONTRIBUTION TO DJANGO

[Heba Khan]

Hi Tom! 
 
Thank you so much for taking time out and answering my queries. However, 
I'm still unclear about how to move ahead with all the guidelines suggested 
by you. I would be extremely grateful if you could guide me a bit more with 
respect to all your suggestions.

On Friday, 22 September 2017 14:51:46 UTC+5:30, Tom Forbes wrote:
>
> Hey Heba,
> For a few popular packages on Github it could be as simple as making a 
> merge request and changing their tox.ini or travis.yml file. Once the 
> django 2.0 alpha is published on PyPi (sometime very soon) you could make a 
> merge request to run the projects tests with the alpha, and inspect the CI 
> output for any failures, then fix those. Alternatively, clone each project 
> and run the tests locally (but this can get tiring for lots of individual 
> different projects).
>
> For example, django-reversion has a tox.ini here: 
> https://github.com/etianen/django-reversion/blob/master/tox.ini - If you 
> make a merge request to that project adding Django 2.0 alpha to the `deps` 
> section (line ~16) and the `test` section (line 4) it will run the tests on 
> Travis CI and report any failures. You could post on the django-users 
> mailing list for some ideas of what packages to make changes for (and for 
> more help with specific things like tox/travis), but I would recommend: 
> django-reversion, django-mptt, silk and django-debug-toolbar:
>
> https://github.com/etianen/django-reversion/blob/master/tox.ini
> https://github.com/django-mptt/django-mptt/blob/master/tox.ini
> https://github.com/jazzband/silk/blob/master/.travis.yml
> https://github.com/jazzband/django-debug-toolbar/blob/master/tox.ini
>
> An initial merge request testing on Django 2.0 alpha is the first step, 
> then fixing any issues that are discovered is the next (and harder) one.
>
> On Thu, Sep 21, 2017 at 6:55 PM, Heba Khan  > wrote:
>
>> Can you suggest a way of how to test Django projects ad third party 
>> packages please?
>>
>> On Thursday, 21 September 2017 21:00:36 UTC+5:30, Adam Johnson wrote:
>>>
>>> There's a whole documentation page on this: 
>>> https://docs.djangoproject.com/en/dev/internals/contributing/
>>>
>>> There aren't many easy pickings tickets, plus most of the effort right 
>>> now is being put into features for the 2.0 feature freeze. I'd suggest the 
>>> biggest contribution you can make right now is testing Django projects or 
>>> third party packages with 2.0 and finding bugs or helping them become 
>>> compatible.
>>>
>>> On 21 September 2017 at 15:17, Heba Khan  wrote:
>>>
 Hello! 

 I'm an undergrad student of B.Tech. in Computer Science and we've been 
 assigned a project to contribute in an open source project. My team 
 members 
 and I decided to pick Django since it is one of the most well known and 
 widely used open source projects. We need help in deciding what 
 contributions to make to the repository and how to go about it. Please 
 keep 
 the following in mind:

 1. We're students with Intermediate coding skills and intermediate 
 knowledge of Python along with a good hold on HTML, CSS, JavaScript and 
 JQuery.
 2. We need some easy contribution ideas which can be executed in a 
 short span of time. 
 3. We will be needing guidance and future help from the community as 
 well. 

 Thank you in advance. 

 -- 
 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 post to this group, send email to django-d...@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/236511d3-54de-441a-a423-57cc01143be0%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Adam
>>>
>> -- 
>> 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 post to this group, send email to django-d...@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/c3feb2a3-4cec-4ac2-9bc1-e61e90165913%40googlegroups.com
>>  
>> 

Re: Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

even https://docs.djangoproject.com/en/stable/ directs me to /1.6/ and will 
give me 404. This has been bothering me for a while and I don't know why it 
doesn't happen to many. I set up a brand new laptop yesterday and still 
have the same issue.

On Friday, September 22, 2017 at 7:38:10 AM UTC-4, Florian Apolloner wrote:
>
> This is why we already have https://docs.djangoproject.com/en/stable/ 
> links. From a SEO perspective we are going to stay with versioned URLs and 
> redirects.
>
> On Friday, September 22, 2017 at 1:03:26 PM UTC+2, Sai wrote:
>>
>> Guys i have an suggestion.Instead of showing 
>> *https://docs.djangoproject.com/en/1.11/ 
>> * we can show it as 
>> *https://docs.djangoproject.com/en/latest/ 
>> * . Every time we have new 
>> release we can proxy pass */latest *end point to latest version 
>> documentation.It will take time but in few days it will be uniform across 
>> all websites. 
>>
>>  P.H.S.Phanindhra,
>> AE13B020,
>> 4th year Undergraduate,
>> Aerospace Engineering,
>> IIT Madras,Chennai.
>>
>> On 22 September 2017 at 08:08, Dylan Reinhold  wrote:
>>
>>> From the main site, or from other site like stack-overflow or google? 
>>> From the main site I get 1.11.
>>> From another site you cant control what links are used.
>>>
>>> Dylan
>>>
>>> On Thu, Sep 21, 2017 at 6:07 PM, Zhiqiang Liu  
>>> wrote:
>>>
 Most of the times it is redirected to v1.6, sometimes 1.10, not sure 
 why it happens?

 Are people aware of that?


 -- 
 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 post to this group, send email to django-d...@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/98fcb742-83a4-4b5b-ad7a-5b4e8c47769c%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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/CAHtg44A4q2QDnAzWAkcLmqyONp2KM%3DBY_U4UtiEMb8LwutisEA%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/ffbd9c60-7d7e-465b-8c8f-ef65ac19e128%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Zhiqiang Liu]

+1, also it is a good point that all things in settings should be simple, 
complex date object does not belong there, at least should not be required.

It should be for the majority of users as possible.

On Friday, September 22, 2017 at 4:53:55 AM UTC-4, Adam Johnson wrote:
>
> +1 for consistency too. You can always use a timedelta if you want, with 
> total_seconds() (not seconds as mentioned before).
>
> On 22 September 2017 at 08:48, Florian Apolloner  > wrote:
>
>> +1 for consistency
>>
>> On Friday, September 22, 2017 at 2:46:14 AM UTC+2, Collin Anderson wrote:
>>>
>>> Seconds is consistent with all of the other settings, even for long ones 
>>> like CSRF_COOKIE_AGE and SESSION_COOKIE_AGE. It also means you can avoid 
>>> importing datetime in your settings file.
>>>
>>> On Thu, Sep 21, 2017 at 8:36 PM, Tom Forbes  wrote:
>>>
 It also seems odd to express it as seconds, it's often going to be a 
 large value between an hour and several days and the lowest resolution for 
 the value anyone would need is minutes.

 On 22 Sep 2017 01:29, "Tom Forbes"  wrote:

> I would still vote for a timedelta, im not sure if there is a strong 
> consensus in the thread. 
>
> Representing the time as seconds always irks me, you can make it more 
> readable by using multiplication but you often end up with a comment 
> anyway 
> and it doesn't scan nearly as well. Having to do 'timedelta.seconds' is 
> OK, 
> but it seems a bit like busywork. 
>
> It's a small thing but I don't see any practical problem with just 
> accepting a timedelta, they are nicer to work with in the settings file 
> itself and within Django, especially if the TimestampSigner accepts them 
> natively and we start to use that.
>
> On 21 Sep 2017 22:41, "Zhiqiang Liu"  wrote:
>
> If most agree, I will proceed with using seconds.
>
> It is a good idea for the potential documentation Dylan!
>
> Zach
>
>
> On Thursday, September 21, 2017 at 10:09:50 AM UTC-4, Dylan Reinhold 
> wrote:
>
>> I still think seconds are the way to go, but maybe the documentation 
>> could give a clue that timedelta().seconds can be used for readability
>> PASSWORD_RESET_TIMEOUT = datetime.timedelta(hours=6, 
>> minutes=30).seconds
>>
>> Dylan
>>
>> On Thu, Sep 21, 2017 at 6:14 AM, Zhiqiang Liu  
>> wrote:
>>
>>> Yeah I don't think float number of days is a good choice because the 
>>> calculation will be weird with precision issues.
>>>
>>> I think it makes sense to use PASSWORD_RESET_TIMEOUT. For timedelta 
>>> vs. integer seconds. Timedelta has the benefit of readability, but 
>>> integer 
>>> has the benefit of simplicity. I think in SETTINGS everything should be 
>>> as 
>>> simple as possible, so I think integer seconds is a better choice here. 
>>> And 
>>> it is used in most applications too.
>>>
>>>
>>> On Thursday, September 21, 2017 at 8:56:36 AM UTC-4, charettes wrote:

 That's what I proposed on the ticket but I feel like it felt odd to 
 me, the setting name does't suggest this is possible and it might be 
 hard 
 to achieve exact second precious because of float rounding?

 In my opinion introducing PASSWORD_RESET_TIMEOUT with timedelta 
 support would be the best option.

 Simon

 Le jeudi 21 septembre 2017 05:26:23 UTC-4, Adam Johnson a écrit :
>
> Why not just keep PASSWORD_RESET_TIMEOUT_DAYS and allow floats? 
> Then you can just do 1/24 for an hour.
>
> On 21 September 2017 at 09:50, Eddy C  
> wrote:
>
>> I think Minute, with default value 30 or 60, is the best unit for 
>> this setting.
>>
>> 3 minutes (even 1) is short enough for edge case and 720 (12 
>> hours) also looks good.
>>
>> On Thursday, September 21, 2017 at 6:22:20 PM UTC+10, Tom Forbes 
>> wrote:
>>>
>>> I think we shouldn't shoe-horn a timedelta into the existing 
>>> setting, so my vote is with the second option, but I think a 
>>> timedelta is 
>>> much more readable than just an integer.
>>>
>>> Also, the existing 3 day timeout for password links is quite 
>>> surprising from a security point of view. The consultants I work 
>>> with would 
>>> flag up a token that lasts longer than 12 hours as an issue during 
>>> a 
>>> pentest. 
>>>
>>> IMO a new, far shorter default should be added to this setting.
>>>
>>> On 21 Sep 2017 03:56, "Zhiqiang Liu"  wrote:
>>>
>>> I need 

Re: ConnectionResetError in test_closes_connection_without_content_length

[Chris Foresman]

The problem is the version of SQLite included in recent versions of macOS. The 
easiest fix we saw was installing Homebrew and then doing a `brew install 
sqlite`. 

-- 
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/9752c6d9-9faf-4dcb-9359-a9ba0866062f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why Django Document site always redirect to an earlier version

[phani p]

Guys i have an suggestion.Instead of showing
*https://docs.djangoproject.com/en/1.11/
* we can show it as
*https://docs.djangoproject.com/en/latest/
* . Every time we have new
release we can proxy pass */latest *end point to latest version
documentation.It will take time but in few days it will be uniform across
all websites.

 P.H.S.Phanindhra,
AE13B020,
4th year Undergraduate,
Aerospace Engineering,
IIT Madras,Chennai.

On 22 September 2017 at 08:08, Dylan Reinhold  wrote:

> From the main site, or from other site like stack-overflow or google? From
> the main site I get 1.11.
> From another site you cant control what links are used.
>
> Dylan
>
> On Thu, Sep 21, 2017 at 6:07 PM, Zhiqiang Liu 
> wrote:
>
>> Most of the times it is redirected to v1.6, sometimes 1.10, not sure why
>> it happens?
>>
>> Are people aware of that?
>>
>>
>> --
>> 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/ms
>> gid/django-developers/98fcb742-83a4-4b5b-ad7a-5b4e8c47769c%
>> 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/CAHtg44A4q2QDnAzWAkcLmqyONp2KM
> %3DBY_U4UtiEMb8LwutisEA%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/CAM6ybf5Uz7vRb93JdhzNvu-T4RP5-H8eTVKRpQ9GxT18-pRUow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: There should be a way to make Templates substitution to raise an exception on error

[Sjoerd Job Postmus]

Indeed it could be!

What if it was not `string_if_invalid` but `if_invalid`. The value could be:

* An Exception instance (which would then be raised)
* An Exception class (which would be instantiated with the "invalid" 
thing), and then be raised
* A callable (which would be called, and must return a string or raise), 
and the result used (unless it raises an exception, in which case that 
exception is propogated upwards)
* A string (which would be interpolated with `%` if it contains "%s") to be 
used instead.

(in that order).

We also use the `string_if_invalid` trick with a custom class that provides 
`__mod__`/`__contains__`. Would be great if we could handle that at the 
Django layer.

On Friday, September 22, 2017 at 11:00:00 AM UTC+2, Adam Johnson wrote:
>
> I've used a solution like the one Emil links to before to great success, 
> though perhaps there's scope to make it a bit less hacky in Django.
>
> On 22 September 2017 at 07:10, Emil Stenström  
> wrote:
>
>> It as actually possible, just in a very hacky way. Django has a setting 
>> called TEMPLATE_STRING_IF_INVALID (or TEMPLATES[0]["OPTIONS"]["
>> string_if_invalid"] in current versions of Django). If you override it 
>> and set it to a class with a __str__ that raises an exception you can get 
>> the effect you want. We use this in tests to find missing variables quickly.
>>
>> Reference code: https://djangosnippets.org/snippets/646/
>>
>> On Thursday, 21 September 2017 13:05:28 UTC+2, Shreyas Pandya wrote:
>>>
>>> Hi All,
>>>
>>> What is your opinion on having an option to raise an error in template 
>>> if variable is not found in context. This may be useful for automated 
>>>  tests as discussed in ticket. 
>>>
>>> reference ticket #28618  ; 
>>>
>>> Thanks
>>>
>>> regards
>>> Shreyas
>>>
>>
>> -- 
>> 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 post to this group, send email to django-d...@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/02995ca2-2721-4526-89de-408bb3be642d%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Adam
>

-- 
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/e26084e2-da3b-4194-8fe5-018130a941a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CONTRIBUTION TO DJANGO

[Tom Forbes]

Hey Heba,
For a few popular packages on Github it could be as simple as making a
merge request and changing their tox.ini or travis.yml file. Once the
django 2.0 alpha is published on PyPi (sometime very soon) you could make a
merge request to run the projects tests with the alpha, and inspect the CI
output for any failures, then fix those. Alternatively, clone each project
and run the tests locally (but this can get tiring for lots of individual
different projects).

For example, django-reversion has a tox.ini here:
https://github.com/etianen/django-reversion/blob/master/tox.ini - If you
make a merge request to that project adding Django 2.0 alpha to the `deps`
section (line ~16) and the `test` section (line 4) it will run the tests on
Travis CI and report any failures. You could post on the django-users
mailing list for some ideas of what packages to make changes for (and for
more help with specific things like tox/travis), but I would recommend:
django-reversion, django-mptt, silk and django-debug-toolbar:

https://github.com/etianen/django-reversion/blob/master/tox.ini
https://github.com/django-mptt/django-mptt/blob/master/tox.ini
https://github.com/jazzband/silk/blob/master/.travis.yml
https://github.com/jazzband/django-debug-toolbar/blob/master/tox.ini

An initial merge request testing on Django 2.0 alpha is the first step,
then fixing any issues that are discovered is the next (and harder) one.

On Thu, Sep 21, 2017 at 6:55 PM, Heba Khan  wrote:

> Can you suggest a way of how to test Django projects ad third party
> packages please?
>
> On Thursday, 21 September 2017 21:00:36 UTC+5:30, Adam Johnson wrote:
>>
>> There's a whole documentation page on this: https://docs.djangoproje
>> ct.com/en/dev/internals/contributing/
>>
>> There aren't many easy pickings tickets, plus most of the effort right
>> now is being put into features for the 2.0 feature freeze. I'd suggest the
>> biggest contribution you can make right now is testing Django projects or
>> third party packages with 2.0 and finding bugs or helping them become
>> compatible.
>>
>> On 21 September 2017 at 15:17, Heba Khan  wrote:
>>
>>> Hello!
>>>
>>> I'm an undergrad student of B.Tech. in Computer Science and we've been
>>> assigned a project to contribute in an open source project. My team members
>>> and I decided to pick Django since it is one of the most well known and
>>> widely used open source projects. We need help in deciding what
>>> contributions to make to the repository and how to go about it. Please keep
>>> the following in mind:
>>>
>>> 1. We're students with Intermediate coding skills and intermediate
>>> knowledge of Python along with a good hold on HTML, CSS, JavaScript and
>>> JQuery.
>>> 2. We need some easy contribution ideas which can be executed in a short
>>> span of time.
>>> 3. We will be needing guidance and future help from the community as
>>> well.
>>>
>>> Thank you in advance.
>>>
>>> --
>>> 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 post to this group, send email to django-d...@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/ms
>>> gid/django-developers/236511d3-54de-441a-a423-57cc01143be0%
>>> 40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Adam
>>
> --
> 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/c3feb2a3-4cec-4ac2-9bc1-
> e61e90165913%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 

Re: There should be a way to make Templates substitution to raise an exception on error

[Adam Johnson]

I've used a solution like the one Emil links to before to great success,
though perhaps there's scope to make it a bit less hacky in Django.

On 22 September 2017 at 07:10, Emil Stenström  wrote:

> It as actually possible, just in a very hacky way. Django has a setting
> called TEMPLATE_STRING_IF_INVALID (or TEMPLATES[0]["OPTIONS"]["strin
> g_if_invalid"] in current versions of Django). If you override it and set
> it to a class with a __str__ that raises an exception you can get the
> effect you want. We use this in tests to find missing variables quickly.
>
> Reference code: https://djangosnippets.org/snippets/646/
>
> On Thursday, 21 September 2017 13:05:28 UTC+2, Shreyas Pandya wrote:
>>
>> Hi All,
>>
>> What is your opinion on having an option to raise an error in template if
>> variable is not found in context. This may be useful for automated  tests
>> as discussed in ticket.
>>
>> reference ticket #28618  ;
>>
>> Thanks
>>
>> regards
>> Shreyas
>>
>
> --
> 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/02995ca2-2721-4526-89de-
> 408bb3be642d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM2RDaGtMzu%2B93nuFP0DS6%2BFa1ZM8PQeaavoa%3D%2BASKGaVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Feature: Allow password reset token to expire in under a day

[Adam Johnson]

+1 for consistency too. You can always use a timedelta if you want, with
total_seconds() (not seconds as mentioned before).

On 22 September 2017 at 08:48, Florian Apolloner 
wrote:

> +1 for consistency
>
> On Friday, September 22, 2017 at 2:46:14 AM UTC+2, Collin Anderson wrote:
>>
>> Seconds is consistent with all of the other settings, even for long ones
>> like CSRF_COOKIE_AGE and SESSION_COOKIE_AGE. It also means you can avoid
>> importing datetime in your settings file.
>>
>> On Thu, Sep 21, 2017 at 8:36 PM, Tom Forbes  wrote:
>>
>>> It also seems odd to express it as seconds, it's often going to be a
>>> large value between an hour and several days and the lowest resolution for
>>> the value anyone would need is minutes.
>>>
>>> On 22 Sep 2017 01:29, "Tom Forbes"  wrote:
>>>
 I would still vote for a timedelta, im not sure if there is a strong
 consensus in the thread.

 Representing the time as seconds always irks me, you can make it more
 readable by using multiplication but you often end up with a comment anyway
 and it doesn't scan nearly as well. Having to do 'timedelta.seconds' is OK,
 but it seems a bit like busywork.

 It's a small thing but I don't see any practical problem with just
 accepting a timedelta, they are nicer to work with in the settings file
 itself and within Django, especially if the TimestampSigner accepts them
 natively and we start to use that.

 On 21 Sep 2017 22:41, "Zhiqiang Liu"  wrote:

 If most agree, I will proceed with using seconds.

 It is a good idea for the potential documentation Dylan!

 Zach


 On Thursday, September 21, 2017 at 10:09:50 AM UTC-4, Dylan Reinhold
 wrote:

> I still think seconds are the way to go, but maybe the documentation
> could give a clue that timedelta().seconds can be used for readability
> PASSWORD_RESET_TIMEOUT = datetime.timedelta(hours=6,
> minutes=30).seconds
>
> Dylan
>
> On Thu, Sep 21, 2017 at 6:14 AM, Zhiqiang Liu 
> wrote:
>
>> Yeah I don't think float number of days is a good choice because the
>> calculation will be weird with precision issues.
>>
>> I think it makes sense to use PASSWORD_RESET_TIMEOUT. For timedelta
>> vs. integer seconds. Timedelta has the benefit of readability, but 
>> integer
>> has the benefit of simplicity. I think in SETTINGS everything should be 
>> as
>> simple as possible, so I think integer seconds is a better choice here. 
>> And
>> it is used in most applications too.
>>
>>
>> On Thursday, September 21, 2017 at 8:56:36 AM UTC-4, charettes wrote:
>>>
>>> That's what I proposed on the ticket but I feel like it felt odd to
>>> me, the setting name does't suggest this is possible and it might be 
>>> hard
>>> to achieve exact second precious because of float rounding?
>>>
>>> In my opinion introducing PASSWORD_RESET_TIMEOUT with timedelta
>>> support would be the best option.
>>>
>>> Simon
>>>
>>> Le jeudi 21 septembre 2017 05:26:23 UTC-4, Adam Johnson a écrit :

 Why not just keep PASSWORD_RESET_TIMEOUT_DAYS and allow floats?
 Then you can just do 1/24 for an hour.

 On 21 September 2017 at 09:50, Eddy C  wrote:

> I think Minute, with default value 30 or 60, is the best unit for
> this setting.
>
> 3 minutes (even 1) is short enough for edge case and 720 (12
> hours) also looks good.
>
> On Thursday, September 21, 2017 at 6:22:20 PM UTC+10, Tom Forbes
> wrote:
>>
>> I think we shouldn't shoe-horn a timedelta into the existing
>> setting, so my vote is with the second option, but I think a 
>> timedelta is
>> much more readable than just an integer.
>>
>> Also, the existing 3 day timeout for password links is quite
>> surprising from a security point of view. The consultants I work 
>> with would
>> flag up a token that lasts longer than 12 hours as an issue during a
>> pentest.
>>
>> IMO a new, far shorter default should be added to this setting.
>>
>> On 21 Sep 2017 03:56, "Zhiqiang Liu"  wrote:
>>
>> I need general consensus on how to proceed with supporting
>> password expire time to be under a day. Currently it is not possible
>> because we use PASSWORD_RESET_TIMEOUT_DAYS.
>>
>> In ticket 28622  we
>> have two options.
>>
>> One is to continue to use the same setting
>> PASSWORD_RESET_TIMEOUT_DAYS, but change the value to non-integer 
>> (such as