Re: CONTRIBUTION TO DJANGO

[Alexander Lyabah]

Django Doc has several pages about testing

https://docs.djangoproject.com/en/1.11/intro/tutorial05/
https://docs.djangoproject.com/en/1.11/topics/testing/tools/
https://docs.djangoproject.com/en/1.11/topics/testing/advanced/

On Thursday, September 21, 2017 at 8:55:59 PM UTC+3, 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-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/c717589e-d276-4e73-93a3-3d1e1b662910%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Dylan Reinhold]

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

Re: status of 2.0 release blockers

[Tim Graham]

completed today:
https://github.com/django/django/pull/9086 - Refs #28595 -- Added execute 
wrappers for database queries.

I plan to merge this last one early tomorrow, then release the alpha later 
in the day.
https://github.com/django/django/pull/9081 - Fixed #27332 -- Added support 
for conditional joins in the ORM.

On Wednesday, September 20, 2017 at 9:18:17 PM UTC-4, Tim Graham wrote:
>
> completed today:
> https://github.com/django/django/pull/7482 - Simplified URL routing 
> syntax. (code)
> https://github.com/django/django/pull/9072 - Simplified URL routing 
> syntax. (docs)
> 
> https://github.com/django/django/pull/9100 
> 
>  
> - Fixed #28488 -- Reallowed error handlers to access CSRF tokens.
>
> 
> todo:
> https://github.com/django/django/pull/9086 - Refs #28595 -- Added execute 
> wrappers for database queries.
> https://github.com/django/django/pull/9081 - Fixed #27332 -- Added 
> support for conditional joins in the ORM.
>
> I hope to finish those two issues tomorrow and release the alpha on Friday 
> or Saturday. Thanks to everyone who's been helping to work on and review 
> the remaining PRs. :-)
>
> On Monday, September 18, 2017 at 9:44:05 PM UTC-4, Tim Graham wrote:
>>
>> completed today:
>> https://github.com/django/django/pull/6385 - Fixed #14370 -- Added 
>> select2 widget for related object fields in admin.
>> https://github.com/django/django/pull/7611 - Fixed #26608 -- Add support 
>> for OVER-clause (window expressions).
>>
>> 
>> todo:
>> https://github.com/django/django/pull/7482 - Simplified URL routing 
>> syntax. (code)
>> https://github.com/django/django/pull/9072 - Simplified URL routing 
>> syntax. (docs)
>> https://github.com/django/django/pull/9086 - Refs #28595 -- Added 
>> execute wrappers for database queries.
>> https://github.com/django/django/pull/9081 - Fixed #27332 -- Added 
>> support for conditional joins in the ORM.
>>
>> On Sunday, September 17, 2017 at 5:11:43 PM UTC-4, Florian Apolloner 
>> wrote:
>>>
>>> Looks good to me. 
>>> https://github.com/django/django/commit/01c6a3e227b645e8dea97e9befecd23d1d3b8581
>>>  
>>> resulted in test failures, we might have to revert that.
>>>
>>> I do have to add https://github.com/django/django/pull/9100 to the mix, 
>>> but since it is a bugfix we can easily do this after the alpha.
>>>
>>> cheers,
>>> Florian
>>>
>>> On Sunday, September 17, 2017 at 1:30:01 AM UTC+2, Tim Graham wrote:

 Time to kickoff the progress tracker for the next major release!

 The 2.0 alpha is scheduled (according to 
 https://code.djangoproject.com/wiki/Version2.0Roadmap) for Monday, 
 September 18. Typically we've release the alpha a few days later to finish 
 up a few last minutes things. Here are the PRs on my list to polish off 
 before the alpha release. I'll send another update on Monday.

 https://github.com/django/django/pull/6385 - Fixed #14370 -- Added 
 select2 widget for related object fields in admin.
 https://github.com/django/django/pull/7611 - Fixed #26608 -- Add 
 support for OVER-clause (window expressions).
 https://github.com/django/django/pull/7482 - Simplified URL routing 
 syntax. (code)
 https://github.com/django/django/pull/9072 - Simplified URL routing 
 syntax. (docs)
 https://github.com/django/django/pull/9086 - Refs #28595 -- Added 
 execute wrappers for database queries.
 https://github.com/django/django/pull/9081 - Fixed #27332 -- Added 
 support for conditional joins in the ORM.

>>>
>>>

-- 
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/6cae5b79-1665-4754-8c7f-33aac76bd0c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ConnectionResetError in test_closes_connection_without_content_length

[Zhiqiang Liu]

To follow up, I set up a new macbook pro today with python3.6 and OXS10.12, 
and I got the same error.

On Wednesday, September 20, 2017 at 8:39:23 PM UTC-4, Zhiqiang Liu wrote:
>
> Yeah I believe it is a new test, so I can't test if it is working for 1.11.
>>
>
> I did get it to pass after adding except like this
>
>  try:
> conn.request('GET', '/example_view/', headers={'Connection': 
> 'keep-alive'})
> response = conn.getresponse().read()
> conn.request('GET', '/example_view/', headers={'Connection': 
> 'close'})
> with self.assertRaises(RemoteDisconnected, msg='Server did not 
> close the connection'):
> try:
> conn.getresponse()
> except ConnectionAbortedError:
> if sys.platform == 'win32':
> self.skipTest('Ignore nondeterministic failure on 
> Windows.')
> except ConnectionResetError:
> self.skipTest('Ignore failure.')
>
> Tom because you said it varies by OS, so I am not sure which message to 
> add so I just used 'Ignore failure', should I use something else? I can 
> submit a simple PR for 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/msgid/django-developers/1aa49196-ef38-418f-8aa0-57e3c9d806cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Why Django Document site always redirect to an earlier version

[Zhiqiang Liu]

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/msgid/django-developers/98fcb742-83a4-4b5b-ad7a-5b4e8c47769c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Permissions Scheme

[Ramez Ashraf]

My proposal is mainly about re-thinking how permissions work with Django as
a whole, as It's not the most perfect thing. And fixing it in a backward
compatible way is next to impossible, so i would say let's revolutionize it
and try to ease the transition.

Regarding adding a view permission (for example) , with my approach, the
developer would have to change the Base model the Permission is inheriting
from (Or go and swap the model all together as with user).
With the new advice from Django to create own user model at the start of
each project (even if it's not needed), maybe we will start see more
Swapped Users models then what we see now.

Permission like `can_do_something` will (and should) still be supported.

Regarding User.has_perm, i think the method can be enhanced to accept model
instance, or model_name and the action name. along side with the current
implementation.

My Approach will -of course- help with the translation as it there is no
strings in the database.
Also the idea is about how to make the permissions flexible, to give the
developers more accurate control.
Again with this approach,  the developer can add extra field(s) to the
"model permission" which can be anything which he/she can use.
I'll make a repo soon for demonstration.


On Thu, Sep 21, 2017 at 11:19 PM, ludovic coues  wrote:

> There are a lot of issue with your new permissions.
>
> Some people have been asking for a view permission in admin. With
> current system, all one have to do is add a permission per model. With
> your proposal, the whole system have to be ditched in favor of a more
> flexible one.
>
> I have also seen production code using permission like is_something.
> Yeah, sure, it's not semantically correct. Being a bot or a moderator
> or a senior user is not a permission. But current permission system
> work nicely for that kind of stuff.
>
> Yeah, sure, people can swap the model like with user. But I have seem
> more often code adding a foreign key pointing to the user rather than
> swapping the model. I doubt that kind of solution will work with stuff
> like user.has_perm().
>
> In a nutshell, what you propose will break a lot of code, require more
> work from developer, won't really help with translation and the only
> help with the widget because you are cutting most of the useful stuff
> out of the permission system.
>
> 2017-09-21 22:14 GMT+02:00 Ramez Ashraf :
> > Good day dear fellow Django developers,
> >
> > Current permissions scheme in Django does suffer many flaws
> > Like Inconsistency with permissions for proxy models #11154 and the fact
> > that permission names are not translatable (no translation in the
> database)
> > and the Permission Widget (FilteredSelect) is not very user friendly if
> we
> > have a lot of models.
> > Some of these issues have some work around like gists creating correct
> > permissions for proxy models, widgets to display the permissions in a
> > translated Tabular format (django-tabular-permissions)
> > But the problems are still there.
> > And the current implementation in itself is some what naive, only add ,
> > change , delete
> > Maybe i can delete only the records created by me, maybe i can delete but
> > not older then 1 day unless i'm superuser
> >
> > I want to suggest a complete Permission makeover
> > Basically a new model / db table for User permissions which look
> something
> > like this (and another one for the groups of course.)
> >
> > user_id | contenttype_id | add  | change| delete
> > 1   | 1  | True | True| False
> >
> > The new model can be swap-able (like the User model) so end developers
> might
> > add more specified fields beside the add , change,  delete like (can edit
> > other users entries, limit to date etc.)
> > It might be also advised to create your own Permission model at the
> start of
> > the project (like what is happening now with the user model)
> >
> > And the current Permissions table can be used for the custom permissions
> .
> >
> > I understand that this is might not be the most backward compatible
> solution
> > (although if accepted by you, we can figure this out, using data
> migrations
> > or something)
> >
> > But Permissions in Django have been dragging for far too long, and
> delaying
> > fixing them if not helping.
> > I see the new simplified url (and letting go of the regular expressions-
> at
> > least up front) and i say wow, things can change. :-)
> >
> > Looking forward for your much appreciated input, ideas & discussion.
> >
> > Thank you for your time reading this and Best wishes to all of you.
> >
> >
> > Ramez
> >
> >
> >
> >
> >
> >
> > --
> > 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 

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

[Collin Anderson]

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
 timedelta) so we can send hours, minutes, etc to it.

 The other one is to create a new setting like
 PASSWORD_RESET_TIMEOUT which takes seconds.To support backward
 compatibility, I think we should keep PASSWORD_RESET_TIMEOUT_DAYS and 
 its
 default value of 3. Only use PASSWORD_RESET_TIMEOUT when provided.

 I'm unsure which one is better, so inputs are welcome.

 --
 You received this message because you are subscribed to the Google
 Groups "Django 

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

[Tom Forbes]

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
>>> timedelta) so we can send hours, minutes, etc to it.
>>>
>>> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT
>>> which takes seconds.To support backward compatibility, I think we should
>>> keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use
>>> PASSWORD_RESET_TIMEOUT when provided.
>>>
>>> I'm unsure which one is better, so inputs are welcome.
>>>
>>> --
>>> 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/grou
>>> p/django-developers.
>>> To view this discussion on the web 

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

[Tom Forbes]

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
>> timedelta) so we can send hours, minutes, etc to it.
>>
>> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT
>> which takes seconds.To support backward compatibility, I think we should
>> keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use
>> PASSWORD_RESET_TIMEOUT when provided.
>>
>> I'm unsure which one is better, so inputs are welcome.
>>
>> --
>> 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/c8e96008
>> -eb95-4924-8e5e-9b02d6b90c99%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
> You 

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

[Zhiqiang Liu]

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 
>> timedelta) so we can send hours, minutes, etc to it.
>>
>> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT 
>> which takes seconds.To support backward compatibility, I think we should 
>> keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
>> PASSWORD_RESET_TIMEOUT when provided.
>>
>> I'm unsure which one is better, so inputs are welcome.
>>
>> -- 
>> 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/c8e96008-eb95-4924-8e5e-9b02d6b90c99%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/6d0d4251-64bc-40a0-b191-9cf3dfe8c91b%40googlegroups.com
>  
> 

New Permissions Scheme

[Ramez Ashraf]

Good day dear fellow Django developers,

Current permissions scheme in Django does suffer many flaws
Like Inconsistency with permissions for proxy models #11154 
 and the fact that permission 
names are not translatable (no translation in the database) and the 
Permission Widget (FilteredSelect) is not very user friendly if we have a 
lot of models.
Some of these issues have some work around like gists creating correct 
permissions for proxy models, widgets to display the permissions in a 
translated Tabular format (django-tabular-permissions)
But the problems are still there. 
And the current implementation in itself is some what naive, only add , 
change , delete 
Maybe i can delete only the records created by me, maybe i can delete but 
not older then 1 day unless i'm superuser

I want to suggest a complete Permission makeover
Basically a new model / db table for User permissions which look something 
like this (and another one for the groups of course.)

user_id | contenttype_id | add  | change| delete
1   | 1  | True | True| False

The new model can be swap-able (like the User model) so end developers 
might add more specified fields beside the add , change,  delete like (can 
edit other users entries, limit to date etc.) 
It might be also advised to create your own Permission model at the start 
of the project (like what is happening now with the user model) 

And the current Permissions table can be used for the custom permissions .

I understand that this is might not be the most backward compatible 
solution (although if accepted by you, we can figure this out, using data 
migrations or something)

But Permissions in Django have been dragging for far too long, and delaying 
fixing them if not helping. 
I see the new simplified url (and letting go of the regular expressions- at 
least up front) and i say wow, things can change. :-)

Looking forward for your much appreciated input, ideas & discussion.

Thank you for your time reading this and Best wishes to all of you.


Ramez






-- 
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/bbdf1910-6b89-4568-8c1b-a681b5807871%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Methodology for increasing the number of PBKDF2 iterations

[Tim Graham]

It's time to decide how much to bump the iterations for Django 2.1 -- 
anyone care to make a proposal? My understanding is that we should revisit 
the current "bump by 20% each release" guideline in Django's release 
checklist. Django 2.0 uses 100,000 iterations.

On Sunday, February 12, 2017 at 1:12:47 PM UTC-5, Martin Koistinen wrote:
>
> If anyone is still following this thread... =)
>
> I've just updated the Google sheet above with significant changes. I was 
> using the wrong values for PBKDF2-HMAC-SHA256 hash performance. I now have 
> up-to-date hw costs and new evidence in play. Definitely worth having a 
> look at the latest version. The up-side is PBKDF2 is significantly better 
> than was previously calculated.
>
> Enjoy!
>
> On Monday, January 30, 2017 at 2:09:56 PM UTC-5, Martin Koistinen wrote:
>>
>> *IMPORTANT NOTICE:* I've just made an important change to the Google 
>> Docs Sheet here: 
>> https://docs.google.com/spreadsheets/d/16_KdYAW03sb86-w_AFFnM79IaTWQ7Ugx4T0VMfGteTM/edit?usp=sharing
>>
>> Realizing that most security policies make requirements such as "At least 
>> 1 character must be a numeral", etc. for other character classes, I've 
>> adjusted this sheet to take this into account *along with the resulting 
>> reduction of password strength that comes with it.* I do recognize that 
>> these symbol-requirements policies are there to force people to choose 
>> passwords that use a broader set of symbols which has the desired effect of 
>> raising password strength, but the actual, theoretical maximum entropy of 
>> the resulting passwords is *significantly *lowered as a result.
>>
>> As a result, a 8-character password formed with at least 1 of each of 
>> these sets:
>>
>>- numerals (10);
>>- lower-case letters (26);
>>- upper-case letters (26);
>>- and punctuation symbols (10-ish);
>>
>> will offer *at most* 40.7 bits of entropy.
>>
>> Passwords of this level of strength, when used on a system that uses 
>> 3 iterations of PBKDF2 will be quickly and easily cracked by virtually 
>> any serious attacker. 100,000 iterations isn't really any better.
>>
>

-- 
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/61c3dede-e2f6-464c-bd09-00e8d1123c01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: CONTRIBUTION TO DJANGO

[Heba Khan]

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

Re: CONTRIBUTION TO DJANGO

[Adam Johnson]

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-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/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/CAMyDDM19%2Br48gXLg%2BRB%2BE%3Deq98MO9W9D1t7RXbD0YoWbDSnaYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

CONTRIBUTION TO DJANGO

[Heba Khan]

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-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/236511d3-54de-441a-a423-57cc01143be0%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

[Dylan Reinhold]

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
> timedelta) so we can send hours, minutes, etc to it.
>
> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT
> which takes seconds.To support backward compatibility, I think we should
> keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use
> PASSWORD_RESET_TIMEOUT when provided.
>
> I'm unsure which one is better, so inputs are welcome.
>
> --
> 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/c8e96008
> -eb95-4924-8e5e-9b02d6b90c99%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/ms
 gid/django-developers/6d0d4251-64bc-40a0-b191-9cf3dfe8c91b%
 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.
> 

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

[Tom Forbes]

You could perhaps emulate that with a template tag, it seems it would be
best if this was kept in the template rather than in some associated Python
file:

@register.simple_tag(takes_context=True)
def requires(context, *names):
for name in names:
if name not in context:
raise RuntimeError('Missing context: {0}'.format(name))

{% requires "name" "other" %}

On Thu, Sep 21, 2017 at 2:37 PM, Zhiqiang Liu  wrote:

> To continue the previous comment.
>
> template can raise error give warning if required contexts are not
> provided or the types are not correct. You can have something not
> isRequired in contextTypes too but types can be check if the context is
> actually passed to template.
>
>
> On Thursday, September 21, 2017 at 9:35:05 AM UTC-4, Zhiqiang Liu wrote:
>>
>> This is not 100% related to the ticket, but something to think about.
>>
>> In ReactJS, there a concept called propTypes, which will check all props
>> (they are similar to context in concept I think) listed with types in UI
>> component.
>>
>> So maybe we can have something similar in django template system that a
>> template can have an attribute called contextTypes and it can be a dict of
>> context the template may have. It doesn't need to have all possible context
>> values, only include those you want to make sure the context are passed and
>> value types are correct.
>>
>> A simple example can be
>>
>>
>> contextTypes = {
>> "name": contextTypes.string.isRequired,
>>
>> }
>>
>>
>>
>> On Thursday, September 21, 2017 at 7:05:28 AM UTC-4, 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/0e82ce82-3a0d-44a6-9f68-
> f359a7354eb9%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/CAFNZOJM2mPKcPD-9wpDMA1-MNe029Wtzz%2B2U8t1wzLzT_UOYUA%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

[Tom Forbes]

You could perhaps emulate something like that with a template tag, couldn't
you?

@register.simple_tag(takes_context=True)
def requires(context, *names):
for name in names:
if name not in context:
raise RuntimeError('{0} is not in the template
context'.format(name))

And in the template:

{% requires "name" "other" %}

Seems that it would be best if that kind of data lived with the template,
rather than outside in a Python file.

On 21 Sep 2017 14:37, "Zhiqiang Liu"  wrote:

> To continue the previous comment.
>
> template can raise error give warning if required contexts are not
> provided or the types are not correct. You can have something not
> isRequired in contextTypes too but types can be check if the context is
> actually passed to template.
>
>
> On Thursday, September 21, 2017 at 9:35:05 AM UTC-4, Zhiqiang Liu wrote:
>>
>> This is not 100% related to the ticket, but something to think about.
>>
>> In ReactJS, there a concept called propTypes, which will check all props
>> (they are similar to context in concept I think) listed with types in UI
>> component.
>>
>> So maybe we can have something similar in django template system that a
>> template can have an attribute called contextTypes and it can be a dict of
>> context the template may have. It doesn't need to have all possible context
>> values, only include those you want to make sure the context are passed and
>> value types are correct.
>>
>> A simple example can be
>>
>>
>> contextTypes = {
>> "name": contextTypes.string.isRequired,
>>
>> }
>>
>>
>>
>> On Thursday, September 21, 2017 at 7:05:28 AM UTC-4, 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/ms
> gid/django-developers/0e82ce82-3a0d-44a6-9f68-f359a7354eb9%
> 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/CAFNZOJOcTUqeaBbeMy8OC%3D_Kf9_1D_Qz2x%3DyTBNSxEBKGgkDgA%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

[Zhiqiang Liu]

To continue the previous comment.

template can raise error give warning if required contexts are not provided 
or the types are not correct. You can have something not isRequired in 
contextTypes too but types can be check if the context is actually passed 
to template.


On Thursday, September 21, 2017 at 9:35:05 AM UTC-4, Zhiqiang Liu wrote:
>
> This is not 100% related to the ticket, but something to think about.
>
> In ReactJS, there a concept called propTypes, which will check all props 
> (they are similar to context in concept I think) listed with types in UI 
> component.
>
> So maybe we can have something similar in django template system that a 
> template can have an attribute called contextTypes and it can be a dict of 
> context the template may have. It doesn't need to have all possible context 
> values, only include those you want to make sure the context are passed and 
> value types are correct.
>
> A simple example can be
>
>
> contextTypes = {
> "name": contextTypes.string.isRequired,
>
> }
>
>
>
> On Thursday, September 21, 2017 at 7:05:28 AM UTC-4, 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/0e82ce82-3a0d-44a6-9f68-f359a7354eb9%40googlegroups.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

[Zhiqiang Liu]

This is not 100% related to the ticket, but something to think about.

In ReactJS, there a concept called propTypes, which will check all props 
(they are similar to context in concept I think) listed with types in UI 
component.

So maybe we can have something similar in django template system that a 
template can have an attribute called contextTypes and it can be a dict of 
context the template may have. It doesn't need to have all possible context 
values, only include those you want to make sure the context are passed and 
value types are correct.

A simple example can be


contextTypes = {
"name": contextTypes.string.isRequired,

}



On Thursday, September 21, 2017 at 7:05:28 AM UTC-4, 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/46bb3674-3eeb-4b8c-8599-7950036e92f4%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]

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 timedelta) so we can send 
 hours, minutes, etc to it.

 The other one is to create a new setting like PASSWORD_RESET_TIMEOUT 
 which takes seconds.To support backward compatibility, I think we should 
 keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
 PASSWORD_RESET_TIMEOUT when provided.

 I'm unsure which one is better, so inputs are welcome.

 -- 
 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/c8e96008-eb95-4924-8e5e-9b02d6b90c99%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/6d0d4251-64bc-40a0-b191-9cf3dfe8c91b%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 

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

[charettes]

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 timedelta) so we can send 
>>> hours, minutes, etc to it.
>>>
>>> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT 
>>> which takes seconds.To support backward compatibility, I think we should 
>>> keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
>>> PASSWORD_RESET_TIMEOUT when provided.
>>>
>>> I'm unsure which one is better, so inputs are welcome.
>>>
>>> -- 
>>> 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/c8e96008-eb95-4924-8e5e-9b02d6b90c99%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/6d0d4251-64bc-40a0-b191-9cf3dfe8c91b%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/002ecd87-ed82-45d4-a66b-6e57b4fcfe15%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

[Dylan Reinhold]

I agree about deprecating PASSWORD_RESET_TIMEOUT_DAYS, with no rush to
remove. Then if PASSWORD_RESET_TIMEOUT it takes precedent.
Now for the input to PASSWORD_RESET_TIMEOUT looking at current settings in
django, anything I found that is time/age based is expressed in integer
seconds.
I would say stay with seconds,

Dylan

On Wed, Sep 20, 2017 at 7:56 PM, 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 timedelta) so we can send
> hours, minutes, etc to it.
>
> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT which
> takes seconds.To support backward compatibility, I think we should keep
> PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use
> PASSWORD_RESET_TIMEOUT when provided.
>
> I'm unsure which one is better, so inputs are welcome.
>
> --
> 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/c8e96008-eb95-4924-8e5e-
> 9b02d6b90c99%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/CAHtg44B_yZrfeY%3DrwS%3DzjpyUwY%3DbJCSH6DXGD24%3DNP3nyiqeHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Shreyas Pandya]

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/5f6dfee4-c869-4e61-88aa-4e54d0eb31bc%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

[Adam Johnson]

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 timedelta) so we can send
>> hours, minutes, etc to it.
>>
>> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT
>> which takes seconds.To support backward compatibility, I think we should
>> keep PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use
>> PASSWORD_RESET_TIMEOUT when provided.
>>
>> I'm unsure which one is better, so inputs are welcome.
>>
>> --
>> 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/c8e96008-eb95-4924-8e5e-9b02d6b90c99%
>> 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/6d0d4251-64bc-40a0-b191-
> 9cf3dfe8c91b%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/CAMyDDM2Y-krvLkKwxvNp%3DEuLa-oMDhuB%2BkxABwE5Ae76LOPPdw%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

[Eddy C]

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 timedelta) so we can send 
> hours, minutes, etc to it.
>
> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT which 
> takes seconds.To support backward compatibility, I think we should keep 
> PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
> PASSWORD_RESET_TIMEOUT when provided.
>
> I'm unsure which one is better, so inputs are welcome.
>
> -- 
> 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/c8e96008-eb95-4924-8e5e-9b02d6b90c99%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/6d0d4251-64bc-40a0-b191-9cf3dfe8c91b%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

[Sjoerd Job Postmus]

To be honest, I'm quite surprised that the password reset feature does not 
use `TimestampSigner` which already supports timedeltas explicitly.

Is the Signing backend overkill for this? Probably yes. But I think using 
the signing backend still makes sense since it's already there. So if one 
were to move from day-based timeouts to second/timedelta based timeouts, 
one might as well use the TimestampSigner.

On Thursday, September 21, 2017 at 10:22:20 AM UTC+2, 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 timedelta) so we can send 
> hours, minutes, etc to it.
>
> The other one is to create a new setting like PASSWORD_RESET_TIMEOUT which 
> takes seconds.To support backward compatibility, I think we should keep 
> PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
> PASSWORD_RESET_TIMEOUT when provided.
>
> I'm unsure which one is better, so inputs are welcome.
>
> -- 
> 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/c8e96008-eb95-4924-8e5e-9b02d6b90c99%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/ec9588a0-5193-4b11-8087-0d00441e8275%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

[Tom Forbes]

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 timedelta) so we can send hours,
minutes, etc to it.

The other one is to create a new setting like PASSWORD_RESET_TIMEOUT which
takes seconds.To support backward compatibility, I think we should keep
PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use
PASSWORD_RESET_TIMEOUT when provided.

I'm unsure which one is better, so inputs are welcome.

-- 
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/c8e96008-eb95-4924-8e5e-9b02d6b90c99%
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/CAFNZOJMiAMnOefVvoX1ewp_%2B05%2B4y%2BOzRrpq9nEC7vO%2Bt57kGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.