Re: Removing url() ?

[Alasdair Nicol]

Hi,

On Tuesday, 5 May 2020 21:39:35 UTC+1, James Bennett wrote:
>
>
> There's also no reason why url() in particular should be given special 
> treatment that other deprecated features or APIs don't get. Some other 
> old-time bits went far more quickly: render_to_response(), for example, got 
> the standard deprecation cycle, and was removed for good in 3.0. The old 
> django.core.urlresolvers module went away in 2.0. We've also long since 
> gotten rid of the patterns() helper in favor of just defining URLs as a 
> standard Python list. All of those were "useless code churn" -- the 
> previous functions/modules worked just fine, after all. But they're all 
> gone, and if you run on a supported Django version you've either dealt with 
> those changes or (in the case of render_to_response()) will deal with them 
> sometime in the near future.
>
>
render_to_response was superseded by render in 1.3, but it wasn't removed 
until Django 3.0. The discussion on deprecating it is here [1].

In retrospect I think we should have removed it sooner, because I saw many 
beginners getting CSRF errors when they used render_to_response without 
context_instance=RequestContext(request). 

I'm in favour of removing url() in 4.0. I think it's less likely to catch 
out users than render_to_response, but I do see beginners doing things like 
url('', ...). If we remove url() then some of that will be avoided. 
Hopefully we won't see too many occurrences of path(r'(?P\d+)', ...)' 
instead.

Cheers,
Alasdair

[1]: https://groups.google.com/d/msg/django-developers/-SeUjUbOfKQ/p6IMnJxuDQAJ

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fe1446f4-21b9-45b5-8b9d-089f97302a5a%40googlegroups.com.

Re: [Feature Request] Having an middleware to be able to force authentication on views by default

[Alasdair Nicol]

Hi,

Creating Django settings is often discouraged, so perhaps it would be 
better to create a subclass of AuthenticationMiddleware instead of adding a 
setting. Then users would update MIDDLEWARE to enable the new functionality.

Cheers,
Alasdair

On Sunday, 15 March 2020 17:46:48 UTC, Mehmet Ince wrote:
>
> Hi Adam,
>
> Thanks for your comments. I was thinking to implemented this as a 
> separated middleware but, as you said, AuthenticationMiddleware is much 
> better place to do it.
>
> I already started to implementing this in AuthenticationMiddleware. I 
> would like to send a PR if it’s okay to everyone ?
>
> I’m not sure it’s okay to discuss this in mailing list but I need a help 
> about naming convention for following variables/class/function:
>
> - Variable name to control this in settings.py. ( FORCE_LOGIN_REQUIRED 
> maybe ? )
> - Mixing name for CBV and decorator name FBV  ( AnonymousUserMixin and 
> @anonymous_user ? )
>
> Thanks,
> M.
>
> On 15 Mar 2020, at 17:13, Adam Johnson > 
> wrote:
>
> Hi Mehmet,
>
> I like your move to fail-closed here. I've certainly seen missing auth 
> decorators as a recurring issue in my career, and I do think as an OWASP 
> top ten we should try tackle it better in the framework.
>
> Your implementation is very few lines of code. It could be made more 
> robust, using the attribute approach that the CSRF middleware uses: 
> https://github.com/django/django/blob/7075d27b0c75f1431f29497f4353cd742906b357/django/middleware/csrf.py#L209
>  
> . And it could easily be added to django.contrib.auth, and the default 
> project template. AuthenticationMiddleware doesn't in fact have a 
> process_view method at current, so we could even add it there with a 
> setting to control it.
>
> I doubt many would be against it as an optional extra.
>
> Thanks,
>
> Adam
>
> On Sun, 15 Mar 2020 at 06:36, Václav Řehák  > wrote:
>
>> Hi Tobias,
>>
>> Dne sobota 14. března 2020 9:44:16 UTC+1 Tobias Bengfort napsal(a):
>>>
>>>
>>> Another option could be to add system checks for this: Instead of 
>>> silently "fixing" missing code it would inform developers about missing 
>>> decorators/mixins. (If I have time I might try to come up with a 
>>> prototype of this.)
>>
>>
>> my thinking about this is exactly the same as yours. I have seen issues 
>> with developers forgetting to add LoginRequiredMixin almost on all projects 
>> I worked on and I think all of this issues would have been prevented if the 
>> developers were force to explicitly specify the desired authentication 
>> requirements for each view (probably using the checks system).
>>
>> In my current project we added a testcase to go through all urls in 
>> urlconf and compare then to whitelist of public urls. But it is ugly as it 
>> hardcodes urls as strings (similar to the django-utils repo) defeating the 
>> flexibility of url patterns.
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/4c13eb8d-eb6a-4973-be4d-5abe0fc55bb9%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> 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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM3Ui3shxaspquwhbvT0%2BrbhJXfkC4Sd8bw-zcS_2u0Q5A%40mail.gmail.com
>  
> 
> .
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f3916d6d-77c0-4e40-b201-aaabfe2abd58%40googlegroups.com.

Re: [Feature Request] DetailView, DeleteView, UpdateView should not work with only slug and primary key field?

[Alasdair Nicol]

Hi,

You can already use any unique field as the slug field, for example:

path('product//', views.ProductDetail.as_view()),

ProductDetail(DetailView)
model = Product
slug_field = 'order_id'

If you want to use a different name in the URL pattern, then 
set slug_url_kwarg [1].

path('product//', views.ProductDetail.as_view()),

ProductDetail(DetailView)
model = Product
slug_field = 'order_id'
slug_url_kwarg = 'order_id'

Cheers,
Alasdair

On Wednesday, 2 January 2019 12:24:00 UTC, Osezele Orukpe wrote:
>
> Django class based generic views like DetailView, DeleteView and 
> UpdateView should be flexible enough to work with any unique field not just 
> slug and primary key field,
> In real projects primary key and slugs are  not used fetch data, a more 
> abstract unique key is preferred.
> Yes, this can be easily done on our own but django can just ease that 
> extra stress by making these generic classes flexible enough to work with 
> any field of our choice in
> the model given that the field is flagged as a unique field.
>
> so we could just use the DatailView as so:
>
> ProductDetail(DetailView):
> model = Product
> field = order_id
>
> instead of having to write a custom query(with the ORM) to fetch with 
> 'order_id'
>
>

-- 
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/ffa51fce-b9c8-4d52-bb10-fd75ff503bd0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow usage of widgets in generic class-based views?

[Alasdair Nicol]

This is getting into django-users territory, but I wanted to point out that 
it's often better to leave out the field instead of using a hidden input.

You can then override the form_valid() method, and set the value before the 
form is saved.

class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
model = models.Patient
fields = ['name', 'caregiver_name', 'sex', 'birth_date',
  'residence']


def form_valid(self, form):

form.instance.country = get_country()  # e.g. get country from 
self.request.user

return super().form_valid(form)


Cheers,
Alasdair


On Wednesday, 5 December 2018 16:06:57 UTC, Dan F wrote:
>
> Ah, I see.
>
> It looks like I can use modelform_factory. So:
>
> class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
> model = models.Patient
> fields = ['name', 'caregiver_name', 'sex', 'birth_date',
>   'residence', 'country']
>
> becomes
>
> from django.forms.models import modelform_factory
>
> _patient_create_form = modelform_factory(
> models.Patient,
> fields=['name', 'caregiver_name', 'sex', 'birth_date',
> 'residence', 'country'])
>
> class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
> form_class = _patient_create_form
> template_name = 'healthdbapp/patient_form.html'
>
> and then I can add the widgets:
>
> from django.forms import HiddenInput
>
> from django.forms.models import modelform_factory
>
> _patient_create_form = modelform_factory(
> models.Patient,
> fields=['name', 'caregiver_name', 'sex', 'birth_date',
> 'residence', 'country'],
> widgets={'country': HiddenInput()})
>
>
> class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
> form_class = _patient_create_form
> template_name = 'healthdbapp/patient_form.html'
>
>
> Works for me.
>
> On Tue, Dec 4, 2018 at 5:04 PM charettes > 
> wrote:
>
>> I agree with Tim that this is a slippery slope.
>>
>> Maybe that adding a ModelFormMixin.get_form_class_options() that returns 
>> a
>> {'fields': self.fields} dict by default and is passed to 
>> modelform_factory(**kwargs)
>> in get_form_class() would be a good compromise? 
>>
>> Best,
>> Simon
>>
>> On Tuesday, December 4, 2018 17:28:39 UTC-5, Tim Graham wrote:
>>>
>>> What I meant is that modelform_factory() also has these parameters:
>>>
>>> localized_fields is a list of names of fields which should be localized.
>>>
>>> labels is a dictionary of model field names mapped to a label.
>>>
>>> help_texts is a dictionary of model field names mapped to a help text.
>>>
>>> error_messages is a dictionary of model field names mapped to a 
>>> dictionary of error messages.
>>> field_classes is a dictionary of model field names mapped to a form 
>>> field class. 
>>>
>>> If we accept the patch for widgets, then are we headed down the road of 
>>> adding support for the rest of those arguments? Customizing a form directly 
>>> rather than indirectly via the view seems like better design to me. It 
>>> doesn't require adding features to ModelFormMixin as they are added to 
>>> ModelForm.
>>>
>>> On Tuesday, December 4, 2018 at 4:57:40 PM UTC-5, Dan F wrote:

 https://code.djangoproject.com/ticket/24589

 This ticket has a patch to pass through the "widgets" argument for 
 generic class-based views.

 It was closed with "won't fix" with this comment: "*I don't think the 
 possibility of saving a few lines of user code justifies the complexity of 
 reimplementing the parameters to modelform_factory() as CBV parameters and 
 methods.*"

 I don't understand. The patch was quite small (doesn't seem complex), 
 and it could give everyone the ability to overload widgets.

 Aside from just saving lines of code, it also would act more as 
 expected. I tried using "widgets" before seeing that it didn't work. Also, 
 it would support not making a new form class where every field just has to 
 be copied (useless boilerplate).

 Can you accept the patch?

>>> -- 
>> 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/0281164b-9bf7-485f-83ad-
>> c0301630c91a%40googlegroups.com 
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message 

Re: Spaces between argument separator and argument in template filter generate error

[Alasdair Nicol]

On Friday, 1 June 2018 03:06:01 UTC+1, Collin Anderson wrote:

> Maybe it would be worth having a more friendly error message?
>
>
I agree, it would be good to improve the message.

I've also seen users confused by the "could not parse the remainder" 
message when they forget the spaces around boolean operators, for example:

{% if foo=='bar' %}

On Thu, May 31, 2018 at 8:59 PM, > wrote:
>
>> Thank you for your reply.
>> I understand your opinion well
>>
>> 2018년 5월 31일 목요일 오전 11시 41분 22초 UTC+9, oli...@kidsnote.com 님의 말:
>>>
>>> In the template filter system now,
>>>
>>> spaces between augment separator and augments generate error.
>>> For example, the following template code generates the following error.
>>>
>>> {{ value | filter: "arg"}}
>>>
>>> TemplateSyntaxError at /
>>> Could not parse the remainder: ': "arg"' from 'value | filter: "arg"'
>>>
>>> https://code.djangoproject.com/ticket/29457
>>>
>>>
>>> What do you think of this ticket?
>>>
>>> -- 
>> 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/b133457b-e474-47b6-b37f-cdab3fa6ee2f%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/4747632d-4b1e-43f5-a99f-11b2efbaa49f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #28788: Add support for Model.clean_

[Alasdair Nicol]

On Thursday, 9 November 2017 16:57:22 UTC, Alasdair Nicol wrote:
>
> On Thursday, 9 November 2017 16:37:50 UTC, Matthew Pava wrote:
>
>> I don’t use Field.validators much myself, but it seems that the Form 
>> clean method also calls Field.validators, so the redundancy is already 
>> there in the Form class.  For consistency’s sake, I suggest we either add 
>> Model.clean_fieldname(), or we remove Form.clean_fieldname().  Both 
>> suggestions would certainly have issues with backwards compatibility.
>>
>>
> I don't think that Form.clean_fieldname() shouldn't be removed.
>

Sorry, double negative. I meant "I think that Form.clean_fieldname() should 
not be removed."

-- 
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/48e5fa3a-0ee3-4d47-bd88-e14bd28abbd7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #28788: Add support for Model.clean_

[Alasdair Nicol]

On Thursday, 9 November 2017 16:37:50 UTC, Matthew Pava wrote:

> I don’t use Field.validators much myself, but it seems that the Form clean 
> method also calls Field.validators, so the redundancy is already there in 
> the Form class.  For consistency’s sake, I suggest we either add 
> Model.clean_fieldname(), or we remove Form.clean_fieldname().  Both 
> suggestions would certainly have issues with backwards compatibility.
>
>
I don't think that Form.clean_fieldname() shouldn't be removed. Validators 
only check whether the value is valid or not. They do not allow you to 
modify the value (e.g. "return value.strip()" to remove leading/trailing 
whitespace).

I think that adding Model.clean_ would be useful, and would make 
it more consistent with the form validation. However, backwards 
compatibility is an issue as Jonas mentioned.

cheers,
Alasdair

-- 
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/b96a7405-74f8-41cc-af5e-00a7e0889eac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RedirectView failing silently on NoReverseMatch is confusing

[Alasdair Nicol]

On Thursday, 19 January 2017 12:17:49 UTC, Grzegorz Tężycki wrote:
>
> I think, that method get_redirect_url should raise ImproperlyConfigured 
> error with message "Reverse for '' not found.", or NoReverseMatch 
> exception not should be catch.
>

I would prefer to stop catching NoReverseMatch, rather than raising 
ImproperlyConfigured. I think that

RedirectView(pattern_name='view-does-not-exist').as_view()

should have the same behaviour as 

RedirectView(url=reverse_lazy('view-does-not-exist')).as_view()

-- 
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/004e6f3e-e750-47dd-8469-baf799933fe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template handling of undefined variables

[Alasdair Nicol]

Hi,

On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote:
>
>
>
> On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote:
>>
>> Hi Tim, 
>>
>> On 01/04/2017 03:39 PM, Tim Martin wrote: 
>>  
>> > 1) There are test cases where we have templates that should treat "x 
>> >is y" as True where x and y are both undefined. 
>>
>> Really? Is this an accidental side effect of some historical change, or 
>> really the intent of the test? That behavior seems buggy to me; more 
>> likely to be a bug-magnet than useful. 
>>
>
> There are a couple of test cases in test_if.py: 
> test_if_is_both_variables_missing and 
> test_if_is_not_both_variables_missing. These are verifying this specific 
> case, so they haven't been introduced by accident. I haven't got as far as 
> figuring out whether it was a fully thought through decision or whether 
> someone just created these cases for completeness.
>

I added the tests in ticket 26479 (see comment 5 onwards) [1]. I believe I 
added them for consistency with == and != operators, which have similar 
tests [2], [3] (trickier to spot because they are numbered). I apologise if 
adding the tests has made it harder to improve the behaviour of the tag. 

cheers,
Alasdair

[1]: https://code.djangoproject.com/ticket/26479#comment:5
[2]: 
https://github.com/django/django/blob/master/tests/template_tests/syntax_tests/test_if.py#L85
[3]: 
https://github.com/django/django/blob/master/tests/template_tests/syntax_tests/test_if.py#L112

-- 
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/96f764fa-25c6-4104-9b6b-8226e3b6bd8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing {% include %} to strip a trailing newline

[Alasdair Nicol]

Would adding the future include tag to the builtins in the template OPTIONS 
work? If it did, then you'd only have to make the change to the TEMPLATES 
setting instead of every template.

OPTIONS={
'builtins': ['django.template.future_include'],  # put new include 
in it's own module so that we don't add anything else in future.
}

I'm not familiar with that code, so I don't know whether that would 
override the old include tag. 

Cheers,
Alasdair

On Thursday, 5 January 2017 14:49:58 UTC, Tim Graham wrote:
>
> Hi Simon, I mentioned that idea offhand in an earlier mail, however, I 
> feel that it would be really disruptive to force all projects to go through 
> that deprecation and require adding {% load include from future %} to every 
> template that uses the tag to silence warnings (and then remove those lines 
> sometime after the deprecation ends). (More disruptive than just making a 
> backwards-incompatible change that's likely to affect a (hopefully small) 
> subset of users.) I guess I'm open to it if others think that's the way to 
> go though.
>
> On Thursday, January 5, 2017 at 9:20:36 AM UTC-5, charettes wrote:
>>
>> Hey Tim,
>>
>> I just wanted to mention that another approach for a transition plan 
>> could be
>> to use {% load include from future %} like we did with the {% url %} tag.
>>
>> That doesn't answer the question of whether or not we should make the 
>> change
>> but I think it offers a better upgrade path than a global template option 
>> or
>> a keep_trailing_newline kwarg.
>>
>> Simon
>>
>> Le mercredi 4 janvier 2017 14:58:42 UTC-5, Tim Graham a écrit :
>>>
>>> Shortly after template widget rendering was merged, an issue about extra 
>>> newlines appearing in the rendered output was reported [0]:
>>>
>>> For example, from django-money:
>>>
>>> UIC-Franc
>>> \n\n
>>> US Dollar
>>> \n\n
>>>
>>> The newlines aren't useful and they break assertions like this:
>>>
>>> US Dollar in form.as_p
>>>
>>> --- end report---
>>>
>>> The reporter suggested removing the trailing newline in the attrs.html 
>>> template but Adam Johnson reported: "POSIX states that all text files 
>>> should end with a newline, and some tools break when operating on text 
>>> files missing the final newline. That's why git has the warning \ No 
>>> newline at end of file and Github has a warning symbol for the missing 
>>> newline."
>>>
>>> I suggested that perhaps {% include %} could do .rstrip('\n') on 
>>> whatever it renders.
>>>
>>> Preston pointed out that Jinja2 does something similar:
>>>
>>> http://jinja.pocoo.org/docs/dev/templates/#whitespace-control
>>>
>>>- a single trailing newline is stripped if present
>>>- other whitespace (spaces, tabs, newlines etc.) is returned 
>>>unchanged
>>>
>>> I noted that the issue of {% include %} adding extra newlines was raised 
>>> in #9198 [1] but Malcolm said, "For backwards compatibility reasons we 
>>> cannot change the default behaviour now (there will be templates that rely 
>>> on the newline being inserted)." I was skeptical this would be a burdensome 
>>> change.
>>>
>>> Carl replied:  "It seems quite likely to me that there are templates in 
>>> the wild relying on preservation of the final newline. People render 
>>> preformatted text (e.g. text emails) using DTL. I probably have some text 
>>> email templates in older projects myself that would break with that change. 
>>>
>>> We could add a new option to {% include %}, though." Adam also said, "I 
>>> too have used DTL for text emails that would break under that behaviour. 
>>> New option to include sounds good to me."
>>>
>>>
>>> Me again: In the long run, having {% include %} remove the trailing 
>>> newline seems like a more sensible default. For example, I wouldn't expect 
>>> this code to have a newline inserted between it:
>>>
>>>
>>> {% include "foo.txt" %}
>>> {% include "bar.txt" %}
>>>  
>>>
>>> An option for {% include %} seems superfluous given that if you were 
>>> writing
>>>
>>>
>>> {% include "foo.txt" %}{% include "bar.txt" %}
>>>  
>>>
>>> now you can write the first thing which is much more intuitive.
>>>
>>>
>>> How about a keep_trailing_newline TEMPLATES option for backwards 
>>> compatibility for those who don't want to adapt their templates for the new 
>>> behavior? Jinja2 has that option.
>>>
>>> Carl replied: An engine option may be better than an option to {% 
>>> include %}, though it doesn't allow us to ensure that we strip the 
>>> newline in the specific case of attrs.
>>>
>>> How we default the engine option I guess just depends on how seriously 
>>> we take backwards compatibility. If we default it to strip and make people 
>>> add the config to preserve the old behavior, that's not really backwards 
>>> compatible. Historically (as seen in Malcolm's comment) we would choose to 
>>> err on the side of actual backwards compatibility in a case like this, even 
>>> if it didn't result in the ideal future behavior. But the adaptation isn't 
>>> 

Re: CSRF_COOKIE_HTTPONLY is misleading and not useful

[Alasdair Nicol]

On Monday, 28 November 2016 21:38:14 UTC, Tim Graham wrote:
>
> Meanwhile, there's a ticket [0] asking to expand the documentation of the 
> settings.CSRF_COOKIE_HTTPONLY. If this setting doesn't provide any value, 
> then I figure we should remove the system check that suggests to enable it 
> and deemphasize it in the documentation and/or remove it. Is there 
> consensus on this?
>
 
If CSRF_COOKIE_HTTPONLY isn't effective, then I'm happy for the system 
check to be removed and the documentation to be clarified. However, as a 
user of the setting in the past, I don't think it should be removed. 
Sometimes the functionality is needed to comply with security reports, 
regardless of whether or not the setting is effective.

-- 
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/078c24f0-e951-42f5-8146-914c0eb1123a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Alasdair Nicol]

On Friday, 23 September 2016 07:53:49 UTC+1, Sjoerd Job Postmus wrote:
>
>
> I hope I did not offend you with my post on how the code turned out. That 
> was not my intention, but if it did offend you: my apologies.
>
>
Don't worry, no offence taken :)

Cheers,
Alasdair 

-- 
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/23c04a61-62f3-45bc-8a92-7bb1b08a75d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Challenge teaching Django to beginners: urls.py

[Alasdair Nicol]

On Thursday, 22 September 2016 15:59:12 UTC+1, Sjoerd Job Postmus wrote:
>
> Another part I see is that the high coupling between Django and the URL 
> resolvers (as mentioned in 
> http://sjoerdjob.com/post/is-djangos-url-routing-tightly-coupled/ ) 
> should probably be cleaned up, if it is desired to someday support 
> alternative URL resolvers. I'm willing to provide a patch for the checking 
> part, but I'm not sure if it would be accepted. Do I need to open a ticket 
> for that?
>
> I wrote the initial url checks code. The current tight coupling is the way 
the code turned out, it wasn't a deliberate design choice on my part. I 
read your blog post, and changing the code as you suggest so that the 
resolver can check itself sounds good to me. Yes, please open up a ticket 
to go with your patch.

Cheers,
Alasdair

-- 
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/a6be9d8e-c297-44b9-8ead-8e215f696c7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling Permission-Check from Calling the View

[alasdair . nicol]

On Wednesday, April 27, 2016 at 9:55:57 AM UTC+1, guettli wrote:
>
> Am Dienstag, 26. April 2016 16:27:32 UTC+2 schrieb Alasdair Nicol:
>>
>> I haven't needed to explain why permission has been granted, but I have 
>> had admins asking me why a user is getting permission denied for a 
>> particular view. To answer that, you would
>>
>> 1. Get the url
>> 2. Resolve that to a view
>> 3. Look up the view in the correct views.py, and check which permissions 
>> the permissions_required decorator was using
>>
>> We managed to automate 1. and 2. but not 3. 
>>
>> In Django 1.9, the permission_denied view takes the exception as the 
>> second argument. If the permission_denied decorator included the permission 
>> names in the message when raising PermissionDenied, we would be able to 
>> display the list of permissions in the template. Even better, you could 
>> show the missing permissions, although that would require a larger patch.
>>
>>
> I am not 100% sure I understood you. Do you mean this:
>
> 1. Users/Browser sends http request to django
> 2. App checks the permissions
> 3. App denies the access
> 4. App renders a custom Permission-Denied page which includes the missing 
> perms. 
> Example: "You must not access this page since you don't have the 
> permissions "See Guido naked"
>

Yes, that's what I was trying to build. I would be able to do this in 1.9 
if the decorator did (say)

raise PermissionDenied(permission='See Guido naked')

instead of the current

raise PermissionDenied

I would like to have this, too. But security experts will tell you: "Don't 
> show more than 'permission denied'. Otherwise
> evil hackers get more information and systems get hacked more easily."
>

I understand that, and I am not suggesting that we should show more than 
'permission denied' by default. There was a similar discussion [1] for 
ticket 24733 when discussing whether or not the exception should be passed 
to the view. It's up to the developer what they do with the exception. If 
you were being cautious then you don't need to show the exception 
information to the user. You could log it, or send an email to the admin 
instead.
 

> My steps are like this:
>
> 1, 2, 3 like above
>
> 4. App renders "permission denied. Ask you admin why you must not access 
> the url https://example.com/;
> 5. User goes to admin crying: "I must not access this url, but I want to 
> see "
> 6. Admin enters username and URL in an admin tool, and there he sees: Ah, 
> user is missing perm "See ". 
>   One mouse-click by admin: Now you have the perm :-)
>

I'm not sure that this tool needs to be in Django itself. However, I think 
Django might need a couple of hooks to make it possible to build this tool.

If the login_required decorator set func._login_required = True, and 
permission_required set func._permissions_required = ['see_guido_naked'], 
then it would be possible to resolve a url to a view then introspect the 
view for the _login_required or _permissions_required.

This wouldn't work in all cases (e.g. if we called if has_perm() inside the 
view rather than using the decorator) but I think it would still be useful.

cheers,
Alasdair

[1]: https://groups.google.com/forum/#!topic/django-developers/kcFqjmnlUTQ

-- 
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/aa34f0b9-f88b-4d28-8e64-c7bfbc261c1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling Permission-Check from Calling the View

[Alasdair Nicol]

I haven't needed to explain why permission has been granted, but I have had 
admins asking me why a user is getting permission denied for a particular 
view. To answer that, you would

1. Get the url
2. Resolve that to a view
3. Look up the view in the correct views.py, and check which permissions 
the permissions_required decorator was using

We managed to automate 1. and 2. but not 3. 

In Django 1.9, the permission_denied view takes the exception as the second 
argument. If the permission_denied decorator included the permission names 
in the message when raising PermissionDenied, we would be able to display 
the list of permissions in the template. Even better, you could show the 
missing permissions, although that would require a larger patch.

Another option would be for the permission_required decorator to set a 
_permissions attribute on the decorated view, containing the list of 
permissions. A custom permission_denied view could then introspect the view.

cheers,
Alasdair

On Tuesday, 26 April 2016 14:17:37 UTC+1, guettli wrote:
>
> I would like to decouple the permission checking in django.
>
> Current draw-back: If you use decorators like  [login_required][1], then 
> you can't know in advance whether a user has the permission to do so or not.
>
> I would like to split this into two steps:
>
>  1. check permissions
>  1. call the view.
>
>
> # Use Case 1: Admin tool
> I want an tool for admins where they can check the access-permissions of 
> users. This requires:
>
>  1. The check must not use the current `request.user` since this is the 
> wrong user object.
>  1. The check must not actually call the view, since this might alter data.
>
> # Use Case 2: Show Link as disabled.
>
> I want to show links as disabled (grayed out and without "href") if a user 
> does not have the permission to see linked page.
>
> # Dream
> Returning a boolean for "ok" and "permission denied" is nice. But the big 
> benefit would be if the admin could get a **reason**.
>
> Example: 
>
>  1. Admin opens "Check Perm Tool"
>  1. He selects a view/URL
>  1. The admin hits "submit"
>
>
> Result:
>
> --
> | User | Allowed | Reason
> --
> | fooadmin |  Yes| is_superuser
> | foouser  |  No | missing permission "view-bar-at-midnight"
> | foobar   |  Yes| User has permission "view-bar-at-midnight"
>
> # Question
> How to get this dream come true?
>
>
>   [1]: 
> https://docs.djangoproject.com/en/1.9/topics/auth/default/#django.contrib.auth.decorators.login_required
>
>
>
>
>
>
>
>

-- 
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/59576592-4a44-4d91-b6d4-bde192d8a753%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django template 'if ... is' feature design

[Alasdair Nicol]

On Thursday, 7 April 2016 23:21:37 UTC+1, Ryan Hiebert wrote:
>
>
> > On Apr 7, 2016, at 5:13 PM, Stephen Kelly  > wrote: 
>
> > * Why is there no 'is not' operator? ie '{% if a is not True %}' 
>
> `is not` is probably logical addition, if somebody wants to put in the 
> time to make it happen.


I've created a ticket #26479 to add `is not`.

-- 
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/b72221ac-5ec1-4ce2-9d2e-4635b97d115f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: deprecate or undocument shorcuts.render_to_response()?

[Alasdair Nicol]

I think that updating the docs to use render instead of render_to_response 
is an good change. Many of the CSRF problems that I see new users 
struggling with are solved simply by switching to render.

Since passing context_instance to render_to_response is deprecated in 1.8. 
If I understand correctly, that means that users are already going to have 
to update their code from

return render_to_response('my_template.html',
  my_context,
  context_instance=RequestContext(request))

to

return render(request, 'my_template.html', my_context)

You could argue it's not too much to ask users to change 
render_to_response(template, context) to render(request=None, template, 
context) at the same time.

Cheers,
Alasdair

On Tuesday, 22 December 2015 15:36:57 UTC, Tim Graham wrote:
>
> In 2010/Django 1.3 when the render() shortcut was introduced Jacob 
> proposed: "I think we should deprecate render_to_response() in favor of 
> render(). render_to_response() is just render(request=None, ...), right? 
> Any reason to keep both around?"
>
> Russ replied: "There's no particular reason to keep both around, other 
> than the code churn that deprecation would entail. This is something that I 
> have no problem deprecating on the 2.0 schedule, but migrating every use of 
> render_to_response() over the next 18 months/2 releases seems like an 
> extreme measure to enforce on the entire user base when maintaining 
> render_to_response() doesn't take any real effort."
>
> https://groups.google.com/d/topic/django-developers/mOx9ddVTrPA/discussion
>
> I wonder if there would be consensus to move forward with a deprecation of 
> render_to_response() at this point? If not, we could remove 
> render_to_response() from the docs (as we did with the @permalink 
> decorator), or at least lessen its prominence so it's not confusing to new 
> users about which function to use in new code. I started updating the docs 
> by replacing all usage of render_to_response() with render().
>
> https://github.com/django/django/pull/5853
>

-- 
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/f5203b95-0ed7-4fb0-8088-73829bede644%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: @csrf_protect annoying on django.contrib.auth.views.login

[Alasdair Nicol]

Hi Wim,

On 16/07/15 16:51, Wim Feijen wrote:

Hi,

We are experiencing the same problem when a user changes his language.
We are using a post form for that, see: https://roominreturn.nl .

1. What is annoying is that the csrf Forbidden page is a yellow page and
is shown to the end user. We would never want to confront a visitor with
a yellow Forbidden page with techy remarks. Our default 400-page would
be ok though.


Note that you can avoid the yellow page with the CSRF_FAILURE_VIEW 
setting. The view can be as simple as:


def csrf_failure(request, reason=""):
"""
Friendly view for settings.CSRF_FAILURE_VIEW.
"""
return render(request, 'friendly_csrf_failure_template.html', 
status=403)


Then in your settings add

CSRF_FAILURE_VIEW = 'path.to.csrf_failure';

Cheers,
Alasdair

[1]: https://docs.djangoproject.com/en/1.8/ref/settings/#csrf-failure-view

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55A7D9ED.3030804%40memset.com.
For more options, visit https://groups.google.com/d/optout.

Re: Documenting reporting errors on individual fields in Model.clean (#16986)

[Alasdair Nicol]

Hi,

Thank you Carl and Tim for your replies. I've created a ticket #23865 
and written a patch [1]for the Model.clean() docs [1].


On 17/11/14 16:53, Carl Meyer wrote:

On 11/17/2014 09:48 AM, Tim Graham wrote:

The reasoning for why it wasn't documented is provided here:
https://github.com/django/django/pull/1443#issuecomment-28045150


That comment is actually in favor of documenting it for Model.clean(),
just suggested it be done in a separate PR.

(Personally I think it would be better to document the same technique
for both Model.clean() and Form.clean(), because I don't think
Form.add_error() is significantly easier, and it breaks the API
consistency of "always flag a validation problem by raising
ValidationError", but I guess that's a larger discussion.)


I've been updating a codebase to Django 1.7 this week. Personally, I 
find the add_error API to be more concise when you don't want to raise 
an exception immediately.


class MyForm(forms.Form):
def clean():
if check1():
self.add_error('field1', 'error message')
if check2():
self.add_error('field2', 'error message')

In my models' clean methods, I have to keep track of the errors as I go 
along.


class MyModel(models.Model):
def clean():
errors = {}
if check1():
errors['field1'] = 'error message'
if check2():
errors['field2'] = 'error message'
if errors:
raise ValidationError(errors)

Having said that, it's not that much more difficult, only 3 extra lines 
of code in this case. API consistency is a good argument for documenting 
the ValidationError(dict) approach in both places.


Cheers,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/546B9F58.7070108%40memset.com.
For more options, visit https://groups.google.com/d/optout.

Documenting reporting errors on individual fields in Model.clean (#16986)

[Alasdair Nicol]

Hi,

Ticket #16986 (Model.clean cannot report errors on individual fields) 
was fixed in Django 1.7, but the new feature is not documented. The 
Model.clean() docs still state:


> Any ValidationError exceptions raised by Model.clean() will be stored
> in a special key error dictionary key, NON_FIELD_ERRORS, that is used
> for errors that are tied to the entire model instead of to a specific
> field

The syntax to report an error on an individual field is to pass a dict 
to the ValidationError constructor.


> def clean(self):
>if self.name1 == 'FORBIDDEN_VALUE':
>raise ValidationError({'name1': 
[ValidationError('Model.clean() error messages.')]})


However, this is a private API. There seemed to be some debate in ticket 
#20867 about whether or not to document it.


I'd be happy work on a patch to update the documentation, but I wanted 
to check that it is ok to document this API.


cheers,
Alasdair

--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980.
Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/546A1CCE.6020908%40memset.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: ./manage check to look for models.BooleanField() without default= value.

[Alasdair Nicol]

On Friday, 9 August 2013 01:50:09 UTC+1, Russell Keith-Magee wrote:

>
> On Fri, Aug 9, 2013 at 1:25 AM, Collin Anderson 
> <cmawe...@gmail.com
> > wrote:
>
>> The new ./manage check command is for helping people upgrade to a new 
>> version of django.
>> https://docs.djangoproject.com/en/dev/ref/django-admin/#check
>>
>> django1.6 changes models.BooleanField() to not default to False any more. 
>> This has already bitten me a few times.
>>
>> https://docs.djangoproject.com/en/dev/releases/1.6/#booleanfield-no-longer-defaults-to-false
>>
>> Can we add a warning about BooleanFields without default values to the 
>> "check" command?
>>
>
> Sounds like a good idea to me - this sort of change is exactly what the 
> check command is supposed to be identifying (wherever possible). Ticket and 
> patch welcome!
>
> I've created a ticket for this #20895 and am working on a patch now.

cheers,
Alasdair Nicol

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Additional example for reverse_lazy documentation

[Alasdair Nicol]

Hi,

I like the upcoming reverse_lazy in Django 1.4 (commit 16121). I suggest 
the examples should include using reverse_lazy in urlpatterns.


I just helped a user out in stackoverflow [1] who was struggling with 
NoReverseMatch errors because their url patterns used reverse for 
optional arguments. I think adding an example might stop users from 
struggling with the same problem in future.


My suggested one line addition to the examples in [2] is

 * providing a reversed url in a URL pattern as an extra argument to 
the view function.


On the other hand, I realise that the documentation is stating "some 
common cases", it doesn't have to be exhaustive.


I'd like to make a ticket and patch if people think this is a good idea.

Regards,
Alasdair Nicol

[1]: 
http://stackoverflow.com/questions/6512610/django-url-error-in-template-with-password-change-view/6514169
[2]: 
https://docs.djangoproject.com/en/dev/topics/http/urls/#passing-extra-options-to-view-functions


--
Alasdair Nicol
Developer, MEMSET

mail: alasd...@memset.com
 web: http://www.memset.com/

Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, 
Surrey, GU2 7YD, UK.

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